All use cases
Revenue operations & CRM

Lead distribution without the human touch

Weekly manual lead distribution — two hours on a small market, four to five on a large one, full of judgment calls — redesigned and automated down to 15 minutes flat, on real-time data.

Built for
E-learning — 300+ courses, 6 markets
Google SheetsInternal CRMCustom tooling
15 min
lead distribution per market, any size — down from 2–5 hours
~5%
divergence from an expert's manual layout — inside the zone where the experts disagree with each other
Real-time
data behind every distribution decision — was a weekly snapshot
Nobody here believed this could be automated — there were too many judgment calls in the moment. The automated run took 15 minutes and landed within five percent of what we'd spend hours doing by hand. And that five percent is exactly where our own people would argue with each other and never agree. Now there's one standard.
Head of Sales, e-learning provider

The company

An e-learning provider in business education — finance, marketing, HR, sales, management, and analytics. Over 300 courses, more than 9,300 students across six industries, taught by practitioners from Fortune 500 companies. Multilingual, with a strong presence in the UK, US, and Europe.

The problem

Leads were distributed to sales agents based on their results — conversion and revenue. A system assigned the leads automatically, but the workload rules behind it were set by hand: someone had to weigh each agent's productivity, sales results, and product knowledge, then configure the distribution — for every market, every week.

That meant four things:

  • Two hours per market in the best case — an experienced person on a small market. On a large market, four to five, especially with questions and edge cases in the mix.
  • Human judgment in the loop — with errors, calls that weren't always accurate, and every distributor weighing things their own way.
  • A weekly cadence — the process was too long to run more often, so real-time data never made it into the decisions.
  • The company had the resources to fix this, but not the strategy — no clear picture of what an effective, simple process should look like.

Nobody on the team believed this could be automated. From the inside it looked like pure judgment — too many in-the-moment calls to hand to a machine.

What we did

We split the work into three phases: test the hypothesis, pilot it in the real process, then implement it properly.

01
Process analysis

Collected how the distribution actually works end to end — the milestones, the inputs, the pain points. What looked like judgment turned out to be an unwritten algorithm: if this, then that. Logic people held in their heads, decomposable into rules — with toggles and exceptions for the edge cases they were carrying from memory.

02
Hypotheses and a live pilot

Developed several automation hypotheses, picked one with the stakeholders, and built it as a set of spreadsheets together with the data analytics department. The spreadsheets ran in the real markets — testing both the hypothesis and the process itself, not a mock-up.

03
Iterate, then build

Test runs, side-by-side checks against manual layouts, many corrections — until the pilot held. Through those iterations we wrote the system and process requirements, then the client's IT department built the final tool with us: automated distribution of leads and workload, driven by real-time data.

The payoff

What changed

Distribution takes 15 minutes per market instead of two to five hours — and it doesn't grow with market size, so the system scales to new markets without adding headcount hours.
The algorithm lands within ~5% of an expert's manual layout — the zone where two experts wouldn't agree anyway. One standard instead of opinions.
Decisions run on real-time data instead of last week's snapshot.
Human error left the loop — the system distributes, people only control it.
Sales agents spend the freed time on conversions, not admin.
The layer we built

The client had the resources to build this all along. What was missing was the operating logic — seeing that the "judgment" was an algorithm nobody had written down, designing the process around it, writing the requirements, and walking the path from hypothesis to pilot to tool. That's the layer we built.

Running a process that eats hours of judgment calls every week?

Write us what hurts. Within 24 hours: an honest answer whether we can help, and the next step if we can.

Get in Touch