Most CoE leaders I speak with are confident about their bot utilisation numbers. Their dashboards say 85%, 90%, sometimes 95%. The estate looks healthy. Capacity looks tight. And when the business asks for more throughput, the answer is usually: we need more licences.

 

Except the numbers are often wrong. Most dashboards measure availability, which sounds like utilisation but isn’t.

 

They measure how long a bot was online, logged in, technically ready to work. What they don’t measure is how much of that time the bot was actually doing something useful.

 

One global insurer came to us with exactly this picture. Dashboard said 95% utilisation. The reality, when we looked at actual work completed against available hours, was closer to 30%. A bot available for 440 hours a month was working for 20 minutes. Seven dedicated licences running nine processes when two would have been enough.

 

That’s not an edge case. It’s a pattern we see consistently across large RPA estates. Most are running at somewhere between 30% and 40% true utilisation. The rest is idle time hidden by scheduling gaps, recovery delays, and processes sitting in queues while bots wait for their next scheduled run.

 

The root cause is almost always the same: static scheduling.

 

Bots run on schedules. The business doesn’t. Work arrives when it arrives. Customer queries spike at unpredictable times. Month-end processing creates demand that Tuesday afternoon doesn’t. But the bots are allocated to fixed time slots, running the same processes in the same order regardless of what’s actually queuing up.

 

So you get bots sitting idle at 2pm while queues build up somewhere else. Controllers notice, manually intervene, juggle priorities in spreadsheets, restart failed processes. Skilled developers who were hired to build new automations spend their weeks firefighting instead.

 

And when the pressure mounts, the usual answer is to buy more licences. Which solves the symptom without touching the cause.

 

BN Bank faced this exact situation. A leading Norwegian internet bank running 100+ automated processes. Traditional scheduling couldn’t keep up with customer demand. CSAT scores were dropping. The instinct was to scale up the infrastructure.

 

Instead, they changed how work reached their bots. Moved from static scheduling to SLA-driven orchestration, where work goes to the best available bot based on priority, deadline, and real-time capacity. The schedule is gone. Work runs when it needs to.

 

The results came fast. 62% increase in licence capacity. 84% faster bot response times. Higher customer satisfaction. Same bots, same licences, same infrastructure. No new procurement.

 

Sparebank 1 Samspar took it further. They deliver RPA operations to 10 regional banks in the Sparebank 1 Group. 300+ processes across institutions with different requirements. Controllers were overwhelmed trying to balance the load manually.

 

They onboarded all 10 banks in four days. Response times improved 500% within the first four days of going live. CoE costs dropped 68%. During a three-week development freeze, zero controller actions were needed. The system handled everything.

 

The pattern across both of these, and across the 170+ enterprises we work with, is consistent. The capacity is usually already there. It’s just not being used well. Bots are available but idle. Queues are full but unbalanced. Work is routed to whatever’s scheduled rather than whatever’s optimal.

 

Better orchestration finds that capacity and puts it to work before anyone signs a new licence agreement.

 

One number that sticks with us from the insurer pilot: they went from seven dedicated licences to two. Five licences off the books within weeks. Real money back in the budget.

 

If your dashboards say utilisation is high and your team is still stretched, it’s worth asking what those dashboards are actually measuring. The answer might save you more than you’d expect.