Most automation programs fail commercially before they fail technically. They start with a platform decision instead of a process decision, they are priced by the hour so nobody can say what the end costs, and they are declared finished at go-live, which is the moment the real work starts.
We run engagements in four stages. Each one is priced in advance, each one produces something you own, and you can stop after any of them.
Four stages, each one a separate decision
Assessment
Two to four weeks, fixed fee
We map the processes as they actually run, not as the procedure says. We measure volumes, touch points, cycle times and error rates, and we cost the manual handling. You end with a ranked program: what to automate, in what order, what each step removes, what it costs to build and run, and what could go wrong. It is a document you can take to a board.
- Process inventory with volumes and manual hours
- Feasibility and risk assessment per process
- Ranked roadmap with effort, cost and expected recovery
- Reference architecture for your environment
The assessment stands on its own. If you take it and build internally, it has done its job.
Design
Two to three weeks per program, fixed fee
Before anything is built we write down what the system will decide alone, what it will escalate, how every action is logged and how the control environment is preserved. Integration contracts, data flows and failure behavior are specified. Your security, risk and process owners sign this, not a slide deck.
- Decision boundaries and escalation rules in writing
- Integration and data contracts per system
- Control and audit design, reviewed by your risk function
- Acceptance criteria and accuracy targets per process
This is the stage most programs skip, and it is the one that decides whether the build survives a risk review.
Build and parallel run
Six to twelve weeks per program, fixed scope
We build in your environment, in repositories you own, and then we run the automation alongside the manual process on live volume. Nothing is switched off until outputs match to the accuracy agreed at design. The parallel run is where the exception rate becomes a real number instead of an estimate.
- Working system in your cloud and repositories
- Parallel run on live volume with measured accuracy
- Exception queue sized from real data
- Runbooks, documentation and handover materials
You see working software on real data early, and you keep the manual process until you do not need it.
Operate
Monthly, under a service agreement
Automation is not a project that ends. Volumes shift, policies change, an ERP upgrade breaks an interface, a model version moves. We monitor the estate around the clock, respond to incidents under agreed response times, tune rules and models as the business changes, and report monthly on hours removed and cost avoided.
- 24/7 monitoring with defined response times
- Incident response and root-cause reporting
- Continuous tuning as volumes and policies change
- Monthly reporting on hours removed and cost avoided
Or we hand the estate to your team with the documentation to run it. Both are legitimate endings.
How the money works
We publish the structure. The numbers depend on scope, and you get them in writing before you commit to anything.
Fixed fee for the assessment
Priced before it starts, based on scope rather than hours. You know the number and the deliverable in advance.
Fixed scope for builds
Each program is priced against the design document. Scope changes are quoted; they do not arrive as an invoice at the end.
Monthly fee for operations
Sized to the automation estate and the service level, and reviewed as the estate grows. Typically a fraction of the labor cost the estate removes.
You own what we build
Code, configuration and documentation live in your repositories and your cloud from day one. There is no lock-in mechanism, and leaving does not require our cooperation.
No per-seat licensing on our side
We are not reselling a platform with a headcount meter. Where you need third-party licenses or model usage, those costs are yours directly and visible to you.
Value measured against a baseline you agreed
The manual hours and cost are established in the assessment, before anything is built. Later reporting is measured against that baseline rather than against a claim.
Who you actually get
Senior engineers, not a pyramid
The people in the assessment are the people who build. We do not sell a partner and staff a junior team.
One accountable lead per program
A single named person owns delivery, attends your governance meetings and is reachable when something breaks.
Your people in the room
Process owners and the risk function participate in design. Automation built without them is automation that gets switched off.
Documentation as a deliverable
Runbooks, architecture and decision records are part of acceptance, not a favor at the end.
What buyers ask before the first meeting
It is a fixed fee quoted against the scope: how many processes, how many systems, how many sites. We give you the number before you commit, and it does not move unless you change the scope.
The assessment takes two to four weeks. A first program is typically in parallel run within a quarter. We sequence deliberately so that value starts before the full program is finished.
Then it says that. It has happened, and it is a better outcome than a program that never pays back. You still hold a costed map of your manual work, which is useful on its own.
No. The roadmap is a sequence of independently valuable programs. Each one is a separate decision with its own scope and price.
Yes. We frequently sit alongside an incumbent, take the automation layer and integrate with the platform work they own.
The economics work when there is repetitive volume: enough transactions, documents or contacts that manual handling is a real line in the budget. That is a question the assessment answers directly rather than one we answer by company size.
Start with the assessment
Fixed fee, two to four weeks, and a costed map of your manual work that is yours whatever you decide next.
