Watch the work first.
Most failed automation projects were specified in a meeting room by people describing the process as designed. We start from the task as performed, including the parts that only exist because a system is awkward.
- A few hours with whoever performs the task, not only whoever owns the budget
- One person who can approve a change of direction inside a week
- We start read only. Write access arrives once we can show what it will do with it
Four weeks, in order
We watch the work
We sit with the people doing the task and record what actually happens, including the workarounds nobody documents because they are embarrassing. The gap between the process as described and the process as performed is usually the entire project.
You get a written map at the end of the week whether or not you continue.
We build one path
One task, chosen because it is frequent and boring rather than because it demonstrates well. Narrow enough to finish inside the week, and worth having finished.
We would rather ship one dull thing that works than four impressive things that need supervision.
It runs beside you
The automation runs in parallel with the existing manual process and the two outputs get compared. Disagreements are the point of the week. This is where the cases nobody mentioned in week one turn up, and it is much cheaper to find them here than after cutover.
If the comparison shows it is wrong often enough to matter, we say so and we fix it or we stop. That decision is yours, and it is made on evidence rather than on how much has been spent so far.
Handover
You get the system, the documentation, the reach list, the measured running cost, and the off switch. We walk someone on your team through it while they drive and we watch, rather than the other way round.
On shift, if you want us
Some clients take the handover and run it themselves, which is a good outcome. Some keep us on to watch it and change it as the business moves. We will tell you honestly which one your team is set up for, and being told you do not need a retainer is a normal result here.
Where we differ from the usual pitch
The model is the cheap part
Model choice matters far less than most vendors imply, and it changes every few months anyway. The durable work is the boundary around the model: what it can reach, what it remembers, what it may do without asking, and what it costs to run.
Autonomy is a permission question
A system that runs unattended is one whose limits were decided deliberately. When a firm sells autonomy without showing you the reach list and the escalation path, it is selling the absence of a safety argument.
A demo proves nothing about a Tuesday
Anything looks capable on a curated example. What matters is behaviour on the ugly inputs, the half-filled forms, and the customer who replies to the wrong thread. That is why week three exists.
Improvement has to be measured, not asserted
Claims of hours saved are easy to produce and hard to check. We compare against your own baseline and report the result even when it is unflattering.
Practical detail
- Remote by default, with week one on video or on site within reasonable travel
- Your accounts, your keys. You should not need our permission to keep operating
- Nothing is trained on it, and no copies are retained after handover beyond what you ask us to keep
- Retainers are monthly. If you stop, the systems and documentation are already yours