Automating the refinancing process end to end removed the need to keep a department of ten people on manual operations: roughly twenty thousand dollars a month, around two hundred and forty thousand a year. Conversion into submitted applications rose by fifty to sixty per cent, and not because of a lucky campaign or a one-off push but because of how the process was engineered. Development took about two months, and the first effects appeared as soon as the daily monitoring and the triggered messages were switched on: the system began catching application windows and reminding clients exactly when it mattered.
Every figure in this piece comes from the client. There is no measurement window or calculation formula behind them: how we tell an audited result from a reported one is set out on the cases hub.
How it was: a fragile manual machine
Before automation, a day in the department felt like a forced march across a bog. In the morning, dozens or hundreds of inbound enquiries with nothing paid up front: people are interested in subsidies, grants and compensation but are not paying yet — so revenue is on the horizon while the work is already here. On the screens, a forest of tabs holding the funding operators' sites: each with its own forms, rules and deadlines, and, crucially, each changing constantly and rarely in step with the others. A coordinator keeps a separate spreadsheet of application window dates, someone is manually subscribed to the operators' newsletters, someone watches the news page. Any increase in the marketing budget means a bigger inbound flow, and a bigger flow means hiring. And the more hands there are, the higher the cost of a mistake: a missed message from an operator, a form updated without notice, a deadline moved last night. In that model a manager cannot promise scale: the economics do not hold, manual coordination becomes the bottleneck, and service quality becomes a lottery of the human factor.
Why “hire ten more” does not solve it
The logic is simple: a manual process reproduced tenfold is still manual, only more expensive. Costs grow faster than revenue, and fatigue and turnover erase the effect of temporary wins. A business plan in which every new thousand leads brings ten new coordinators is doomed. We put it bluntly, to ourselves and to the client: to grow, manual labour has to come off the critical path. Putting people at the centre of a process fixes a ceiling. Putting the process at the centre and people on quality control and development opens scale without hiring.
The principles the solution was built on
The team's internal conversation at the time was pragmatic. “If we don't take manual labour out of the centre, we won't grow,” said the product lead. “Getting dates wrong means losing money,” added the head of service. The problem was broken down into six principles for the future solution.
- 1
A single source of truth: all rules and statuses live in one place and are updated daily.
- 2
Personalisation without people: the client receives exactly the steps, documents and links they need, in a legible form.
- 3
Monitoring and events: the system hears for itself when an operator's application window opens and starts the communication itself.
- 4
Orchestration: no magic inside an e-mail, only explicit steps, links and checkable transitions.
- 5
Observability and audit: full logs, versions, retries on failure, anomalies into a parking lane.
- 6
Zero manual touches in normal operation.
From chaos to a pipeline: what we built
The client's path starts with a simple form. The questions are designed to gather the minimum sufficient context: region, client profile, programme type, timing, basic conditions. The completed form lands in a database that serves the whole system as its single source of truth. A normalisation layer sits at the entrance: it brings the answers to one format, removes variation in phrasing, extracts the facts and matches them against the operators' current rules. The output is the chosen operator and the client's personal conditions against the requirements as they stand.
The next move in the pipeline is generating a personal PDF guide. That document is not a memo but a full instruction: step by step, what to do, which documents to collect, where to register, which fields to fill in and by when. The guide carries clickable links to forms and to the operator's own sections, notes on what to watch for, and — most importantly — dated instructions about deadlines. It is assembled automatically and saved to an archive under a naming pattern, so that finding the right version and reconstructing the history stays easy.
The finished PDF goes to the client by e-mail, and at the same time the client is automatically placed into their operator's pool — internal lists that carry status and readiness to apply. Daily monitoring of the operators' sites starts at the same point: news pages, intake and announcement sections, conditions, plus specific signals — “form updated”, “date published”, “document requirements changed”. When monitoring registers a live application window, the orchestrator picks up the event and fires the triggered message: an e-mail with the current instruction and a short SMS urging the client to apply now. The e-mail carries the same personal PDF and a short summary of what changed and what to do today, so that the fewest possible clicks separate the client from the right button.
Orchestration is the control board. It holds the schedulers for monitoring, the retries for when external sites and mail services behave unpredictably, the webhooks that react to the client's actions, and the if-then chains for special cases. Everything the system does is logged. Open, click and delivery tracking makes the communication funnel visible and shows where people fall away. Any anomaly — an operator suddenly pulling a page, say — goes into the parking lane and raises an alert. In normal operation there are no manual touches: a person steps in only when the environment behaves abnormally or when the rules need changing.
- 1Client form
- 2Answer normalisation
- 3Operator matching
- 4Personal PDF guide
- 5Monitoring the operator's site
- 6Application window opens
- 7E-mail and SMS
- 8Application submitted
How it was
6 steps- Hundreds of unpaid enquiries that have to be worked through today
- A forest of tabs with operator sites, each with its own forms and rules
- A coordinator's spreadsheet with application window dates
- Newsletter subscriptions and manual news monitoring
- The client's instruction assembled by hand for each case
- Growth in volume absorbed by hiring more people
How it works now
7 steps- A form collects the minimum sufficient context
- Normalisation checks the answers against current operator rules
- A personal PDF guide is assembled automatically
- An e-mail to the client and a record in the operator's pool
- Daily monitoring of operator sites
- The window opens — an e-mail and an SMS go out
- An anomaly goes to the parking lane and raises an alert
In normal operation the right-hand column has no manual touches: a person steps in when the environment misbehaves or the rules change.
Three scenes where the automation is tangible
Scene one: the manager looks at the dashboard. A month ago they were wary of new campaigns; now they raise traffic calmly. “We're no longer limited by people,” they say, scrolling the summary: in twenty-four hours the system sent hundreds of personal guides, caught two operators opening application windows at once, and raised seven alerts on odd changes to forms. There are no bottlenecks left in the process.
Scene two: the coordinator, the one who used to end up working nights. They watch the PDF guides assemble themselves and go out by e-mail: “Honestly, I always thought instructions had to be written by people. Now I have a versioning button in my hands: I change one block of rules and tomorrow a thousand people get the new guide without a single manual touch.” They smile at the “delivered” and “read” statuses and no longer try to hold everything in their head.
Scene three: the client. In the morning they get an SMS: “The application window for your programme is open. Check your e-mail: the steps and links are there.” They open the message, see the familiar PDF with the “today” markers already highlighted. “Finally it's all clear,” they write back, and an hour later their application is with the operator, complete, with no follow-up questions.
The results in business terms
The loudest effect is resource. Ten full-time roles on manual operations left the P&L, taking twenty thousand dollars a month of operating cost with them — around two hundred and forty thousand a year. The second is conversion into submitted applications rising fifty to sixty per cent: the system forgets nobody, the instructions are always current, and the reminders arrive when the window opens rather than when someone gets round to it. The third is scale without hiring: a hundred, a thousand or more applications a day are workable, because the critical path now holds a pipeline rather than people. The fourth is transparency: there are logs, there is a status for every client, there is a record of when each window opened and how clients behaved in the communications.
The risks and how they are closed
| Risk | How it is covered |
|---|---|
| The operators' reality changes and the instruction goes stale | Daily monitoring of the sources, versioned instructions, strict update discipline. Every change is logged: what was updated, where, when and which version of the rule now applies |
| An operator's site does not answer | Retries at every step: the task does not die but goes back for another attempt |
| An anomaly in the requirements: a section disappears, dates go out of sync | Parked and held for human confirmation |
| The e-mail was not opened | The system follows up by SMS — without assuming why |
| Opened but not clicked | A gentle reminder with the same PDF |
One point deserves emphasis: the system does not invent operator rules, it reads and updates them. Invented dates and conditions are the direct route to losing trust.
A method you can repeat
The case teaches that in any complex administrative procedure it is not intelligence on its own that decides but the wiring of events, rules and triggers. Step one: describe the client's path and isolate the hard artifacts — the instruction, the document list, the links, the calendar of application windows. Step two: gather the operators into one place and agree that this is the source of truth. Step three: choose the orchestrator and the delivery channels, so that the event “window opened” turns automatically into the action “client received the instructions”. Step four: give the client their personal path in a single document, so the fragmentation goes away. Step five: switch on observability — logs, versions, tracking, alerts and retries. And then polish: improve the wording, add context, extend the rules. There is no silver bullet, but there is iron logic: anything expressible as a rule should live in a database rather than in people's heads.
The horizon
A system like this scales. New operators and countries get added — their rules, links and quirks go into the database and monitoring is pointed at other channels. Extra notification channels get connected: messengers, push, reminder calls. Clients get segmented by profile — some care more about fast and simple, others about cheaper and slower — and the wording reflects that choice. Tests appear on phrasing and on the structure of the guide: short versus expanded, question-and-answer versus a step list. Integrations with internal systems open end-to-end metrics: from the first click to LTV it becomes clear which programmes and operators pay back best. For all that freedom to extend, the foundation stays the same: a single source of truth, events as the engine, orchestration as the nervous system and observability as the immune system.
Why development took two months rather than forever
The timeline was decided not by a miracle but by a fairly disciplined plan. We started with a manual beta: built the operator database and checked which form fields repeat reliably. In parallel we wrote the templates for normalising answers and generating instructions, each specifying a role, a goal, quality criteria and the constraint not to invent anything. In the second stage we assembled the orchestration: schedules for monitoring, webhooks for events, retries and branching. In the third we brought up the communications: e-mail templates, short SMS, PDF archives. In the fourth we switched on full logging and alerts, so that every firing was visible. Only then did we let the flow run without manual supervision. The first effects showed immediately: as soon as monitoring started catching application windows and firing triggers, conversion into submissions went up and the queue of “call them and explain it again” went down.
Why this works and will keep working
Because it is built not around one person and their dexterity but around principles that do not age. A single source of truth ends the argument about where the latest version is. Personalisation without people removes the copywriting and coordination bottlenecks. Site monitoring provides reaction speed. Orchestration turns a chain of e-mails and tasks into a checkable system. Observability and alerts provide control. And the fact that no manual touches are needed in normal operation keeps the system cheap to run and able to grow.
Where to start if you want to repeat it
- 1
Map the client's path
Where the interest forms, where the person gets lost, where they do not understand.
- 2
List the operators and rule sources
Links, forms, news channels — everywhere the rules come from today.
- 3
Source of truth and its owner
Where it lives and who is accountable for filling it. Without the second answer the first does not hold.
- 4
Orchestrator and delivery channel
What ties the steps together and how messages reach the client.
- 5
One personal document
So the client sees the whole path instead of assembling it from e-mails.
- 6
Success criteria
The share of applications submitted, the time from first contact to submission, the cost to process.
- 7
Only then automate
First one event-to-e-mail link, then the whole pipeline.
In closing: the ceiling is lifted by a pipeline, not an assistant
This case is about moving from a patchwork manual process to a managed machine where every step has a reason, an input and an output. It is easy to call it striking: zero manual roles instead of ten, two hundred and forty thousand dollars a year off operating cost, fifty to sixty per cent more applications submitted. Behind that sits not a trick but engineering: a single source of truth, personalisation without people, daily monitoring, triggers, orchestration, e-mail and SMS as the system's voice, a PDF generator as the packager, an archive as the memory, and full observability with logs, retries and alerts. Nobody here hopes to make it in time any more — they know the system will remind the client when it matters and give them a legible path in a single document.
Methodology notes, by e-mail
The same material we publish here: how to model the economics of an initiative, where rollouts break, and what to verify before work starts. Once a month at most, no market news and no sales e-mail.
