A case is three clocks, not one

When we talk about “how long issuance takes,” we’re quietly blending three very different things, and keeping them separate is the whole game.

There’s the queue — time a case sits waiting for an agent to pick it up. There’s active handling — the agent actually doing the work. And there’s waiting on the customer — 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.

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 paid lookup. Toggle Sidekick to see what changes.

The point lands before any number does: 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 case reaches the customer without sitting in a queue first.

Notice what we didn’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. 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, 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.

But the cases are so different…

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.

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 shave. It’s a shape change — cases it can resolve at order receipt jump out of the tail and into the clean bucket. 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.

What Sidekick is actually selling

Put the four together and the story isn’t “an AI that handles cases.” It’s four linked mechanisms:

• It acts at order receipt, so easy cases never queue for a human at all.
• It returns capacity, which drains the backlog non-linearly when the team is under load.
• It collapses the expensive tail by resolving hard cases up front.
• It raises first-pass completeness, so a single customer interaction does the job instead of three.

None of these replaces the core system, the workflow engine, or human judgement. Sidekick stays quiet when it has nothing useful to add, and measures even its own silence. The win is speed, consistency, and the agent’s scarce attention spent where it genuinely matters.

These models are only as good as the data behind them. The next step is instrumenting the real workflow — which state transitions we can detect deterministically, and which we must infer — so the figures on this page stop being illustrative and start being measured.