Product Case Study

Capability is not the product

Designing agentic AI around the moment a frontline manager decides what to do next

The demos went well. Beta clients watched Salli read a week of forecast demand against a published schedule, find the shifts that were overstaffed and say what to do about them, and they were impressed. Then they logged in and mostly didn’t use it. In a given week, around one in six managers at accounts with Salli enabled opened it. Over three months the cohort tripled and that number didn’t move.

What they told us was that Salli wasn’t proactive enough. That was an accurate description of the symptom. It took us two attempts to work out what it was pointing at, and both attempts failed in ways that were more useful than the first version working would have been.

The question a restaurant manager actually has, twenty minutes before service, is what do I need to focus on right now. We had built something that could answer it, and no reliable way for it to be asked.

What we built

Harri is an HCM platform used by around two million frontline workers a month, and the people Salli is for are the managers running those sites: balancing labour cost against forecast demand, staying inside multi-jurisdictional compliance rules, and doing it during live service. Workforce tools have historically handed them data and left the interpretation to them, which turns a manager into a part-time analyst at exactly the moment they should be running the floor.

We could have put a chatbot over the platform’s data and shipped it quickly. The bet we made instead was that Salli should do the analysis rather than describe where to find it, and carry out the resulting platform tasks with the manager’s confirmation. Underneath the companion we built a library of bounded agents with specific remits: sales and labour analysis, compliance oversight, timekeeping intelligence, request management, weather impact. Salli was the companion. The agents were topics it could call on, and a manager could switch agent inside a single conversation without losing the thread.

Salli’s agent library open over a schedule, listing Guided learning, Sales snapshot, Labor snapshot, Team communication, Schedule warnings, Compliance oversight and Timekeeping intelligence, opened from an Agents button beside the chat composer.
The agent library and in-chat agent switching, shown in the current build.

The argument I won

As the library grew, a commercial argument arrived with it. Competitors were going to market claiming hundreds of AI agents, and there was a reasonable case for exposing ours the same way, since a visible count is easy to sell and easy to compare.

I argued that the count was the wrong axis. The number of agentic workflows running behind the scenes and the number of choices a manager faces at the point of use are different problems, and treating them as one problem means selling a number to a buyer at the cost of the person on shift. We kept the curated surface.

I’d make the same argument again. But it made no difference to adoption.

Diagram: the same sub-agents, exposed individually or grouped into ten agentsTwo alternatives side by side, with the same number of marks in each. On the left, every sub-agent exposed: an undifferentiated field of identical unlabelled marks. On the right, ten agents: the same marks gathered into ten named groups of unequal size — Guided learning, Sales snapshot, Labor snapshot, Team communication, Schedule warnings, Compliance oversight, Timekeeping intelligence, Team requests, Timesheet review, and Weather impact analysis. Nothing is hidden between the two. Only the grouping differs.every sub-agent exposedten agents exposedGuided learningSales snapshotLabor snapshotTeam communicationSchedule warningsCompliance oversightTimekeeping intelligenceTeam requestsTimesheet reviewWeather impact analysis
The same capability either way. The argument was about how much of its structure a manager has to hold.

Why it wasn’t enough

Surface complexity wasn’t what was wrong. Initiation was.

To get value from Salli you had to open it, and to open it usefully you had to already suspect that something needed your attention. The library’s prompts helped a little with what to ask, but the manager was still guessing which agent was holding something timely, and a manager mid-shift doesn’t have the spare attention to go fishing. Of the managers who did open Salli in a given week, about three quarters opened it on a single day. Almost none used it on three days or more, and nobody used it daily. It never became part of anyone’s routine.

We had set out to remove the burden of interpretation, and replaced it with the burden of knowing what to ask. That’s the chatbot failure in better clothes, which is the thing we had explicitly set out not to build.

Making Salli speak first

So we gave Salli a voice outside the conversation. We designed an alerts highlights popover in the platform header on web, with push and in-app notifications on mobile. A drop in forecast demand that meant the schedule needed adjusting, a new time-off request that conflicted with the published rota, a team member’s birthday coming up. Get the manager’s attention, then draw them into Salli to act on it.

Salli’s alerts on both surfaces. On web, an Alert highlights popover in the platform header stacking business performance, team moments and team requests cards over the schedule. On mobile, a push notification reading “Salli alert — It’s Olivia Brown’s birthday today!” above a sales and labour dashboard.
Right about the content, wrong about the moment.

Three things went wrong, and we found them by watching behaviour and going back to several beta clients.

The mobile notifications arrived while managers were doing something else, usually outside Harri, so they were dismissed in the moment and not returned to later. Salli’s usage on mobile never got above a few per cent of the managers using the Harri mobile app, against roughly a fifth on web, so the surface we were interrupting people on was the one they were least likely to act on. The web popover opened automatically whenever a new alert landed, which our PMs had pushed for and I hadn’t managed to argue them out of, and it was intrusive enough that people resented it. And nothing was prioritised, so anything that could be alerted was alerted, and the alerts became noise.

The alerts were right about the content and wrong about the moment. We’ve kept them, tuned down to what’s genuinely urgent, with auto-open moved behind a user preference. That’s a fix rather than a reversal, because the mechanism was sound and it was the timing and the volume that weren’t.

The same failure twice

The library and the alerts failed for the same reason, and it took us longer than it should have to see it.

The agent library made the manager decide both when to engage and what to ask about. The alerts took both of those decisions away and made them on the system’s schedule, in the middle of whatever the manager was already doing. We had built the two extremes and neither of them was where the work happens.

A manager arriving at the start of a shift will accept an agenda, because working out what today looks like is what they are there to do. The same manager forty minutes into service will not accept an interruption, however good the analysis behind it is. The session should be initiated by the person. The content should be initiated by the system. The design problem in agentic software isn’t what the system can do. It’s who starts, and when. We had never designed that, because we’d been treating proactivity as a property of the product rather than a property of a moment.

Chat and Focus

Salli Focus is the mode we’re building from that. A manager opens it when they log in, at the start of the day or the start of a shift, and it gives them a prioritised set of things that need their attention and what to do about each one, drawn from the same agents that were already there.

Salli Focus open beside the schedule, headed “Here’s your to-dos — I found 8 tasks. I’ve listed them in priority order”, with the first item flagging three time-off requests that need a decision, one colliding with Saturday cover and $210 at risk.
Salli Focus, in design. The manager opens the session, and it opens with an agenda.

The idea came from one of our PMs. We recognised it as the answer to the question we’d just gone back to first principles to ask, rather than a third feature to sit alongside the library and the alerts. My team shaped it into two modes of the same companion. The agent library became Chat, unchanged but no longer carrying the whole burden of getting a manager started. Chat is exploratory and user-led, for when a manager knows what they want to interrogate. Focus is guided and system-led, for when they don’t yet know what today holds.

Who initiates the session and who sets the content, by mode
Session initiated byContent set by
1 – Agent librarypersonperson
2 – Alertssystemsystem
3 – Focuspersonsystem
Focus isn’t a midpoint between the two failures. It’s the combination neither of them had.

It’s in final design now and development starts shortly. The open work is the flows, the trigger points and the onboarding, and I expect onboarding to be the hard part, because a mode that opens with an agenda has to be right early or it teaches people to skip it.

What this was actually about

Every version of Salli has been more capable than the one before it, and capability has never been the constraint. Twice we responded to weak adoption by adding more of it, and twice we made the experience worse: first by giving managers more to choose from, then by giving them more to ignore.

Focus might not work either. But it’s the first version aimed at the question the manager actually has, rather than at a demonstration of what the system knows.