How it works
We start from a process you already repeat, not from a tool. We map what happens now, agree what the automation will and will not do, build and test it against your real data, then run it under monitoring so a silent failure reaches us before it reaches you. The build is a fixed one-time price; keeping it running is separate.
- A fixed price for the build, agreed before anything starts
- Tested against your real data, not a demo account
- Monitored, so you are not the one who finds it broke
- We will tell you when a process is not worth automating
1. We map what happens now
A call and a short written description of the process as it actually runs, including the parts people work around. Most of the value is found here: the step everybody forgets to mention is usually the one causing the errors.
2. We agree the edges before the middle
Before any building, we write down what the automation does, what it refuses to do, and what happens when something upstream fails. What retries, what stops, what must never happen twice. This is the part most automation goes wrong in, and it is cheaper to decide now than to discover later.
3. Fixed price, then build and test
You get a written quote with a fixed price and a date. We build against your real data in a way that cannot touch anything live, and you see it working on your own records before it is switched on.
4. It runs, and we watch it
Automations fail quietly. A token expires, a run stops posting, and nothing announces it - the first sign is usually a figure that does not reconcile at period end, by which point a month of entries are wrong. So every automation we run is monitored, alerts us when a run fails or a credential expires, and gets fixed before you have cause to look.
What we need from you
- Access to the systems being connected, and someone who can authorise it
- A description of the process as it really runs, not as the manual says
- Real examples - a few genuine records beat any amount of description
- One person who can answer questions while we build
When we will tell you not to
A process that runs twice a month, or changes shape every time, is usually not worth automating - the maintenance outlives the saving. So is anything where a person is making a judgement rather than moving data. We would rather lose the work than sell something that quietly costs you more than it saves.
Questions we get asked
Do we need to change the software we use?
Usually not. The point is to connect what you already run rather than move you onto something new. If a system genuinely cannot be connected - no API, no export, no webhook - we will say so early rather than build something fragile around it.
What happens when one of those systems changes?
That is what the recurring fee is for. We watch for API changes and expiring credentials, and fix them before a run fails. An automation nobody maintains is a liability with a shelf life, and we would rather not sell one.
What if the automation does something wrong?
We agree the failure behaviour before we build: what retries, what stops and escalates, and what must never run twice. For anything touching invoices or payments the default is to stop and tell a person rather than guess.
Can we stop paying for Managed Automation?
Yes. The automation is yours and it keeps running. What stops is the monitoring, the alerting and the maintenance - so when something upstream changes, you find out the way you would have before: from a customer.
Tell us what you need built.
Describe the process you repeat and we will tell you whether it is worth automating - including when it is not. A fixed price for the build, quoted before anything starts.