What is Sidekick?

Sidekick is an AI co-pilot for LEI operations. It sits between the moment an order arrives and the moment a human agent opens the case, doing the preparation work automatically so that agents spend their attention only where it genuinely matters. For straightforward cases that work means Sidekick completes the issuance without any human touch. For complex cases it means an agent arrives at a fully staged workspace rather than a blank canvas.

Sidekick integrates with your existing workflow engine and case management system. It does not replace them. It adds a layer of structured intelligence at order receipt that is otherwise missing — and measures its own performance so the models on this page stop being illustrative and start being facts.

How it fits in

Sidekick receives an event from your system when an order is created, runs its assessment, and writes its findings back as structured case notes. The agent sees those notes when they open the case. If Sidekick’s confidence is high enough, the case can be auto-approved without opening at all.

Benefits

Sidekick produces four linked improvements to the LEI operation. They compound.

• Easy cases never wait for a human. Orders that meet a clean evidence threshold are issued automatically, typically within seconds of receipt, regardless of queue length or time of day.
• Freed capacity drains the backlog non-linearly. When a team is at or near capacity, removing a fraction of the inbound volume has an outsized effect on average wait time. Agents have headroom for the cases that need them.
• The expensive long tail shrinks. Hard cases — those needing paid registry lookups, escalations, or multiple customer contacts — are identified early and staged fully before an agent touches them. Fewer surprises means less rework.
• One customer interaction replaces several. Sidekick composes a single, structured evidence request covering every gap it can identify, rather than letting agents discover them one at a time. First-pass completeness rises; round-trip count falls.

All four effects are modelled on the pages below. Every figure is yours to set.

Features

Automatic evidence assessment

At order receipt, Sidekick queries the available data sources — internal records, linked registries, prior case history — and scores each evidence requirement against the LEI validation rule-set. It does this in parallel, not sequentially, so the whole assessment completes before any human involvement.

Structured case notes

Findings are written back to the case as structured, auditable notes: what was checked, what was found, what is still outstanding, and a recommended next action. Agents do not repeat work Sidekick has already done.

Intelligent customer outreach

Where evidence gaps remain, Sidekick drafts a single consolidated information request covering all outstanding items. It formats this for the applicant’s context — jurisdiction, entity type, prior interactions — and tracks the response. Chaser logic is configurable.

Confidence-gated auto-approval

Cases that meet a configurable completeness and confidence threshold can be approved without opening. The threshold, the rule-set, and the escalation path are all operator-controlled. Sidekick never approves a case outside the parameters you set.

Observability by default

Every action Sidekick takes is logged with a reason code. The aggregate of those logs is what feeds the models on this page — and what will eventually replace the illustrative assumptions with measured ones.

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 modeled; 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 clicking. 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 decisons 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 in 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 paid 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.

What Sidekick is actually doing

Put the four together and the story isn’t “a tool 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.