EdTech / Lead Operations
AI Voice Bot & Internal Tools Retainer for Lead Operations
An embedded AI engineering team shipping a calling platform, lead scoring, reporting and content pipelines on a monthly cycle.
- AI Voice Bot
- Lead Scoring
- RAG
- Small Language Models
- Agentic Workflows
- Auto-QA
100%
of incoming leads scored, profiled and queued automatically
2,000+
partner profiles kept complete and presentation-ready
60-80%
lower inference cost with fine-tuned small models
1 query
replaces manual report compilation
- Monthly cycles of scope alignment and data audit, build and integration, then deployment and handover.
- All data stays inside the client's infrastructure with no external AI API transmission, and IP transfers on delivery each month.
Inference cost is what decides whether a model can be applied to every record or only to the expensive ones — a task-specific small model is what makes scoring everything affordable rather than aspirational.
A business whose growth depends on converting enquiry volume eventually stops being constrained by traffic and starts being constrained by what happens to it. Enquiries arrive through forms, chat, phone and web behaviour, and the information needed to tell a serious one from a casual one is already inside the business — in past conversions, past conversations and past outcomes — sitting unused.
The work that follows is not one system. It is a calling platform, a scoring engine, a reporting layer, a content pipeline: each individually modest, and collectively beyond what a team already running the business can deliver alongside running it. Bought as separate projects they arrive as separate systems that do not share data, which is how an organisation ends up with several tools and no compounding advantage.
Why it is hard
The fixed-scope project is a poor instrument for this shape of work. A statement of work written before anyone has examined the data commits to a specification that the first week of data auditing usually invalidates, and from that point change control consumes the schedule that the specification was supposed to protect.
Contracting for engineers instead moves the problem rather than solving it, because what is actually scarce is not hands but the judgement to decide which of ten possible tools is worth building next. That decision needs someone holding the commercial picture and the data at the same time, which is a different engagement shape from either a fixed project or a staffing arrangement.
What we built
The engagement runs as a monthly delivery cycle rather than a fixed scope: scope aligned against an audit of the data that would have to support it, then build and integration, then deployment and handover — repeating. Each cycle is measured by what is in production at the end of it rather than by progress against a plan written months earlier.
What was built across those cycles shares one spine: outbound calling driven by lead status and follow-up schedule, a scoring engine that turns raw enquiries into a prioritised queue with a briefing for whoever picks it up, a conversational layer over operational, finance and marketing data, and content and coaching pipelines. Because they draw on the same data, each one makes the next cheaper to build.
- A monthly cycle — scope against a data audit, build and integrate, deploy and hand over
- Outbound calling driven by lead status and follow-up schedule, with every call logged
- Enquiries scored into a prioritised queue, each with a briefing for whoever takes it
- Operational, finance and marketing data answerable in plain language
- Task-specific small models fine-tuned on the organisation's own data, cutting inference cost
Questions about this engagement.
Why a retainer rather than a fixed-scope project?
Because in this category the specification is the deliverable most likely to be wrong. What is worth building next depends on what the data will actually support, and that is knowable only after looking at it. A monthly cycle puts the scoping decision after the data audit every time, instead of once at the start; the trade is that the client commits to a cadence rather than to a list.
Why fine-tuned small models rather than a frontier model?
For a narrow task repeated at volume — classifying an enquiry, scoring a transcript — a small model tuned on the organisation's own examples matches or beats a general-purpose one at a fraction of the cost per call, and it can run inside the organisation's own infrastructure. Frontier models earn their price on open-ended reasoning, not on making the same kind of judgement a hundred thousand times.
Does this just produce a collection of disconnected internal tools?
That is the failure mode it is arranged to avoid. The tools are sequenced under one engagement specifically so they share a data layer — the scoring engine and the reporting layer read the same records, and the calling platform writes into them. Bought separately as individual projects, each would have arrived with its own store and its own definition of a lead, which is the outcome that makes the fifth tool cost as much as the first.
What this was built on.
Tell us what you're trying to solve.
Describe the workflow, the data behind it, and what a good outcome looks like. We read every message and reply personally.