From first conversation to a system that keeps running.
Every engagement moves through the same six stages. Nothing gets built until it's scoped, nothing goes live without testing and documentation, and nothing is left unmonitored after launch.
- 01 · Week 0
Discovery
We ask about the process as it actually runs today, not the ideal version. Where the work starts, who touches it, where it breaks, and what a good outcome looks like in numbers.
What we ask / map- Walkthrough of the current process, screen-shared
- Which tools and systems already hold the data
- Volume — how often this happens per day or week
- What 'working well' looks like six months from now
We deliver- Every trigger, decision point, and manual handoff
- Systems of record and where data actually lives
- Who needs to be notified and when
What we need from you- 30–45 minutes of a process owner's time
- Read access to the tools involved
- A named point of contact for questions
- 02 · Week 1
Scoping & system design
Before anything is built, we write a blueprint: what triggers what, which integrations are involved, how success is measured, and — just as important — what is explicitly out of scope.
What we ask / map- Sign-off on the blueprint and integration list
- Confirmation of edge cases we've surfaced
- Any constraints on tools, security, or approvals
- A one-page system blueprint
We deliver- A one-page system blueprint
- Full integration list with access requirements
- Success criteria we'll test against at handover
- An explicit out-of-scope list
What we need from you- Written approval of the blueprint
- Admin or API access to relevant systems
- 03 · Weeks 2–4
Build
Work happens in a separate environment against real or realistic data, never in your live systems. Delivery is staged so you see progress at fixed checkpoints, not one reveal at the end.
What we ask / map- Availability for two short review checkpoints
- Fast answers on any open questions we flag
- Staging environment kept isolated from production
- A working slice at each checkpoint, not a demo video
We deliver- Staging environment kept isolated from production
- A working slice at each checkpoint, not a demo video
- A running change log
What we need from you- Review and feedback within an agreed window
- Test data or sandbox credentials, if applicable
- 04 · Week 4–5
Testing & handover
We test against the edge cases and error branches identified during scoping, not just the happy path. Documentation and a live walkthrough come before launch, not after.
What we ask / map- A short session for the team walkthrough
- Sign-off that the system matches the agreed success criteria
- Edge case and error branch test results
- Written documentation of how the system works
We deliver- Edge case and error branch test results
- Written documentation of how the system works
- A recorded or live walkthrough with your team
What we need from you- Attendance from whoever will operate the system day to day
- 05 · Week 5
Deployment
Cutover to production is planned, not improvised — with monitoring and alerting live from the first run, so a failure is caught and flagged, not discovered by a customer.
What we ask / map- A confirmed cutover window
- Confirmation that production credentials are ready
- Staged cutover from staging to production
- Monitoring and alerting on live from day one
We deliver- Staged cutover from staging to production
- Monitoring and alerting on live from day one
- A rollback path if something needs to pause
What we need from you- Production access finalised ahead of the cutover window
- 06 · Monthly, ongoing
Ongoing support & improvement
Systems drift — APIs change, volumes grow, edge cases appear that discovery didn't catch. Monthly maintenance keeps the system healthy and gives you a channel for change requests.
What we ask / map- Flag any process changes on your side that affect the automation
- Monitoring and error handling kept current
- Change requests scoped and delivered monthly
- A quarterly review of performance against the original goals
We deliver- Monitoring and error handling kept current
- Change requests scoped and delivered monthly
- A quarterly review of performance against the original goals
What we need from you- A monthly maintenance arrangement
- Ongoing point of contact for change requests
What the build stage actually produces.
An illustrative example of the kind of flow that comes out of scoping and build — the same shape of diagram you'd see in your own system blueprint.
Inbound lead qualification
From first enquiry to a booked, qualified conversation — no manual triage.
One thread. A clear cadence. No chasing.
Single thread of record
One channel — email or WhatsApp, your choice — carries every decision and update for the project, so nothing gets lost across tools.
Set cadence
Review checkpoints are scheduled at scoping, not improvised. You know in advance when you'll see progress.
Response commitment
Questions raised during an active build get a reply within one business day. Ongoing support requests are acknowledged on the same basis.
Honesty about the edges of a build.
- We won't automate a process before it's clearly mapped — guessing at scope leads to rework.
- We won't launch without monitoring and alerting in place, even if it means a later go-live date.
- We won't touch production systems during the build stage — everything runs in staging first.
- We won't recommend automating a step that a human should keep judgment over.
Timeline and what happens after launch.
How long does a typical build take?
Most single-process automations move from discovery to live deployment in four to six weeks. Larger, multi-system builds take longer — we give you a specific estimate after scoping, not before.
What happens after launch?
The system runs with monitoring and alerting in place. Most clients move into a monthly maintenance arrangement so we keep watching it, fix anything that drifts, and take on new change requests.
Do you build everything from scratch each time?
Design decisions are informed by patterns we've refined across builds — including an internal automation framework we use to keep architecture consistent — but every system is scoped and built for your specific process.
What if our process changes after launch?
That is expected. Change requests are scoped and delivered as part of monthly support, and we review performance against your original goals every quarter.
Ready to see this process applied to your operations?
Send us a short brief and we'll walk you through discovery and an honest timeline for your specific process.