A few weeks. A few automations. Live.
We map where manual effort is going, pick the two to four tasks worth automating, and put them into production on the systems you already run. Measured, documented and handed over.
- Duration
- Three to four weeks
- Output
- Two to four automations running in production
- Platform
- Your existing stack. No Salesforce required
When the work is obvious and nothing moves.
Operations, finance and back-office teams usually know exactly which tasks should be automated. What they lack is an engineering team that can ship two or three of them inside a month.
This is the situation we are usually called into.
The sprint exists because the gap is rarely the idea. It is the delivery.
- A team spends hours each week moving information between systems by hand.
- Documents arrive as email attachments and leave as manually keyed records.
- Everyone can name three things that should be automated, and none of them have moved in a year.
- Internal IT has a backlog measured in quarters, and these tasks will never reach the top of it.
- A previous automation attempt produced a notebook that never ran anywhere real.
- You want to see whether applied AI is worth a larger investment before committing to one.
Automation ideas die between the spreadsheet and the backlog.
The task is well understood, the saving is obvious, and the work still never starts. Three things usually explain it.
Too small to prioritise
Each task is individually too small to win a place on an internal roadmap, while together they consume a meaningful share of a team's week.
Prototype, then nothing
Someone builds a promising proof on their laptop. It never gets the integration, error handling and monitoring that would let operations depend on it.
Waiting on the data programme
Automation gets deferred behind a platform consolidation that is years out. The manual effort continues for the whole of that time.
Six stages,
from map to production.
The scope is narrow deliberately. Two to four automations, engineered properly, beat a dozen half-built ones.
Opportunity mapping
A half-day session with the people doing the work, not only the people managing it.
- Current process walked through step by step
- Time and error cost estimated per task
- Systems, formats and access points identified
- Candidate list built with the team in the room
Scoring and selection
Candidates ranked on value against effort and risk, then cut to the ones that can genuinely ship inside the sprint.
- Effort and value scored openly with you
- Data availability and access confirmed early
- Human-in-the-loop decided per automation
- Two to four selected, the rest held in a backlog
Build
Engineering against your systems, in your environment, with the same standards as any production work we do.
- Integration with email, storage, CRM, ERP or ticketing as required
- Extraction, classification, drafting or routing as the workflow needs
- Version-controlled code in your repositories
- Secrets and credentials handled by your existing mechanism
Evaluation
Accuracy measured on real samples before anything is trusted with real volume.
- Test set drawn from your actual historical cases
- Accuracy measured per automation and written down
- Threshold agreed for what routes to a human
- Edge cases documented rather than hidden
Hardening and deployment
The difference between a script and something your operations team can rely on.
- Failure handling, retries and dead-letter behaviour
- Logging and alerting into your existing monitoring
- Rollback and manual override paths
- Deployment to production with your change process
Handover
Your team owns what we build, with enough documentation to change it without us.
- Runbook covering normal operation and failure
- Working session with the team who will run it
- Architecture and decision notes
- Prioritised backlog of the candidates not built
Working software, and the means to run it.
The sprint is designed to leave nothing behind that only we can operate.
Automations running in production
Two to four workflows live on your systems, processing real work. Not a prototype, not a notebook, not a demonstration environment.
Source code in your repositories
All code committed to repositories you own, with the infrastructure definitions and deployment steps alongside it. No dependency on our accounts or our tooling.
Accuracy baseline
Measured performance per automation on a real test set, with the agreed threshold for human review. You can hold future changes against this number.
Runbook
How each automation operates, what it costs to run, what it does when the source system is unavailable, and how to turn it off safely.
Handover session
A working session with the team who will own the automations, covering monitoring, common failures and how to make a small change safely.
Prioritised backlog
The candidates we did not build, scored and sequenced, so the next sprint starts from analysis rather than from a blank page.
Four weeks, one team.
One engineer leads, with specialist support where the integration demands it. You see working output at the end of the second week.
- Week 1
Map and select
The mapping session, then scoring and selection. By the end of the week the scope is fixed in writing, access is in place and the test sets are agreed.
- Week 2
Build
Engineering on the selected automations, with a working demonstration against real samples at the end of the week. Anything that turns out to be harder than scored is raised then, not at the end.
- Week 3
Evaluate and harden
Accuracy measured on the test sets, thresholds set, failure handling and monitoring added, and deployment run through your change process.
- Week 4
Run and hand over
A week of supervised live running with us watching the logs, then handover: runbook, working session and the backlog. A simple sprint finishes at the end of week three.
What this engagement is not.
A sprint holds its dates because the boundary is fixed. Everything below can be scoped separately once the first automations are running.
- No data warehouse or enterprise data platform build.
- No replacement or migration of your core systems.
- No model training from scratch. We use hosted models and your own data.
- Not a research engagement. If a task needs research, we say so and scope it separately.
- No organisation-wide rollout or change management programme.
- Ongoing operation and support are available, but they are a separate arrangement.
The ones we are asked most.
Do we need our data in one place first?
No. That requirement is what stalls most automation programmes. We work with the systems as they are and integrate at the points where the data already lives.
Which tools and models do you use?
Whatever suits your stack, your data residency position and your existing vendor relationships. We are not reselling a platform, so there is nothing we are incentivised to push.
Who owns the code?
You do. It is committed to your repositories as it is written, not handed over at the end. If you stopped working with us on the final day, everything would keep running.
What if accuracy is not good enough?
We report the measured number rather than talk around it. In most cases a human-review threshold still removes the bulk of the manual effort. Where it does not, we say the automation is not worth deploying.
Does this need Salesforce?
No. This engagement is deliberately platform-neutral. Where you do run Salesforce, we integrate with it the same as any other system.
Can you support it afterwards?
Yes, under a separate support arrangement. It is not bundled, because the sprint is designed to leave you able to run the work yourself if you prefer.
Name the three tasks that waste the most time.
Bring them to a short call. We will tell you which are worth automating now, which are not, and what it would take.