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.

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.
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.

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.

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.
| Session initiated by | Content set by | |
|---|---|---|
| 1 – Agent library | person | person |
| 2 – Alerts | system | system |
| 3 – Focus | person | system |
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.
