← Back to overview

Where does the time go?

Most of the time an LEI case spends in the system is not spent being worked. It is spent waiting — in a queue for an agent, or for a customer to reply. Actual agent effort is a small fraction of the total. That gap is the opportunity Sidekick is designed to close.

The sections below model each part of that gap. Every figure is illustrative and framed around the case, not the individual agent — adjust the sliders to reflect your operation and see each effect respond.

A case is three clocks, not one

When we talk about “how long issuance takes,” we’re actually jumbling three very different things, untangling them brings clarity.

There’s the queue — time a case sits waiting for an agent to pick it up. There’s active handling time — the agent actually doing the work. And there’s waiting on the customer time — the ball in their court after we’ve asked a question.

They run on completely different scales: handling is minutes, the others are hours and days. And they answer different questions — customer experience versus the cost of running the operation.

And there is one more thing that we have not even modelled; we talk here about time, but we are really talking working hours time. In reality, agents and customers stop working at Lunchtime, in the evenings and they go away at the weekends, but the case clock is still ticking. Anything that can be done that means that a question is asked of a customer before they loose context, go home or pack up for the weekend has the potential to knock a day or more off the issuance time. Sidekick can do this by making decisions and asking the customer for more information in minutes of order receipt, while the customer is still at their desk and has the LEI order context in their mind.

Here is a single case, end to end. It’s a “manual director search” — the kind where the registry has no clean API and someone has to do a lookup, or find some other equivalent method to prove Empowerment. Toggle Sidekick to see what changes.

The case takes the better part of a week, and the actual agent work is a sliver of it. Sidekick’s first contribution is to act at order receipt rather than at case open — gathering the evidence and running the checks before a human is ever needed, so the call to action reaches the customer without sitting in a queue first.

Notice what we don’t claim. The re-queue after the customer replies is unchanged. That wait isn’t a property of this case — it’s a property of how busy the team is. Which brings us to the second clock.

Why the backlog explodes

Queue time has a nasty habit: it doesn’t rise gently as the team gets busier. At near full capacity it goes vertical. This isn’t a Sidekick claim — it’s the same mathematics behind every call centre and supermarket checkout. Wait time scales with utilisation as ρ/(1−ρ), and that denominator runs to zero as you approach capacity.

Drag the volume up toward “overwhelmed” and watch it happen. Then toggle Sidekick — which adds no agents at all. It simply cuts the effort each case needs, by an amount you set, which slides the whole team back down the curve, away from the cliff.

This is the second-order win, and it’s the larger one. Every minute of agent effort Sidekick removes is capacity returned to the queue. When a team is near saturation, a modest effort saving collapses the backlog far more than proportionally — because you’ve moved them off the steep part of the curve. The single-case timeline couldn’t show this, because it’s a property of the whole system under load, not of one case. So we measure the case, and model the system.

But this raises the obvious question: where does that effort saving actually come from? It isn’t spread evenly across every case.

Your cases aren’t one population

Treating cases as a single average hides the truth. The reality is a tall spike of easy cases — clean registry APIs, everything automatable — and a long, fat tail of hard ones where directors must be looked up by hand or whole jurisdictions have no API at all, or there are other snarly complications, like L2 or Trusts and Funds.

That shape is why the average misleads. The mean is dragged to the right by the expensive tail, so “average handling time” overstates the typical case and understates the painful one. The honest move is to tariff each archetype separately.

Sidekick’s effect here isn’t a uniform reduction. It’s a shape change — cases it can resolve at order receipt jump out of the tail and into the clean bucket. Set how many you believe it can resolve, and watch the fat tail thin and the clean spike grow.

The median barely needs to move. It’s the expensive P90 cases — the ones that were dragging the average and consuming scarce agent time — that collapse toward the clean path. That tail-collapse is the effort saving the queue model assumed. The two views are the same fact seen from two angles.

There’s one more force that the forward-flowing story has so far ignored — and it may be the biggest of all.

A re-ask costs days, not minutes

Cases rarely flow forward cleanly. When the customer’s reply comes back incomplete, the case loops: another customer wait, another trip through the queue, another touch. And here’s the cruelty of it — a re-ask costs the agent a minute of extra effort but costs the case days of wall-clock, because each loop re-incurs the slow clocks.

So the most powerful lever on issuance time isn’t handling the case faster. It’s asking the customer the right, complete set of questions the first time, so the loop never happens. Sidekick’s structured, mandatory-field forms exist precisely to raise that first-pass completeness.

Every assumption below is yours to set — nothing is pre-judged. And note the fairness of the comparison: every duration is identical whether Sidekick is on or off. A re-ask costs exactly the same. Sidekick’s only job is to make it rarer.

← Back to overview