Turn a repetitive process into a working AI workflow
We help businesses turn repetitive work into reliable workflows across their existing tools. That can include sorting incoming requests, drafting responses, updating records or connecting systems that currently depend on someone copying information between them.
Service 01
No 17040048
Starter scope
From £2,500
Fixed quote after a 20-minute fit call
Covers one workflow. Anything larger, or anything needing custom software, is quoted separately rather than absorbed. Third-party licences and usage costs are stated separately.
Who it is for
- Owners and operations leads at service businesses with one specific, repetitive task that eats hours every week.
- Teams whose systems do not talk to each other, so someone copies information from one to the next.
- Agencies and product teams that have an AI pilot working in a demo and need it to work reliably in production.
What the work covers
Mapping the workflow before building it
A good map shows every step as it actually runs, not as the process document says: where work arrives, who touches it, what they look up, what they decide and where it goes next. It records the exceptions too: the odd request, the missing field, the customer who replies to the wrong address. Most automations that fail were built from the happy path and broke on the first exception nobody wrote down. We build the map from your real examples, including the ones that went wrong, and agree it with you before any building starts, so the quote and the tests describe the same thing.
Deciding where AI belongs, and where it does not
Not every step needs a model. Moving a record, checking a date or routing by a known field is ordinary automation and should stay that way, because it is cheaper, faster and predictable. AI earns its place where the input is messy: reading a free-text request, pulling details out of an email, drafting a reply in your tone. We mark each step in the map as rules, AI or person, and explain why. Keeping AI to the steps that need it makes the workflow easier to test, cheaper to run and simpler to explain to the people who rely on it.
Approval points and human handover
Wherever a mistake would reach a customer, move money or alter a record that matters, the workflow stops and asks a person. We agree those points with you during scoping, then build them so the person sees what the workflow proposes, the information it used and a clear way to approve, edit or reject it. Handover also covers the cases the workflow cannot handle: they go to a named person with the context attached rather than failing silently. ReplyOS uses the same pattern for enquiries, and it is what lets an automation be trusted with real work from the start.
Testing against named cases
Before anything touches live work, we write down the cases the workflow must handle and what should happen in each: ordinary requests, awkward ones, incomplete ones and ones it should refuse or pass to a person. We run them, record the results, fix what breaks and run them again. The cases come from your own redacted examples, so they reflect your work rather than a vendor's demo. You keep the list, which means anyone changing the workflow later can rerun the same cases and see whether it still behaves as agreed.
Seeing what the workflow did
A workflow that runs out of sight is hard to trust and harder to fix. We set up a simple view of outcomes: what came in, what the workflow did with each item, what it passed to people and where it stopped. That view usually lives in a log or a sheet in a tool you already use, not another dashboard to learn. It lets you spot drift early, answer the question 'what happened to this one' quickly, and judge for yourself whether the workflow is earning its place.
A handover your team can live with
At handover you receive the workflow, the access, the documentation and an explanation of any recurring charges. The documentation is written for the person who will look after it: what each step does, where the settings live, how to pause it, what to check if it misbehaves and how to rerun the test cases. Accounts sit in your name, not ours. We review it with you at 30 days, looking at the outcomes together and agreeing anything that needs adjusting.
Typical workflows
These are illustrations of the kind of work, not client results.
Incoming request triage
Requests arrive by email or form, are sorted by type and urgency, and reach the right person with the key details already pulled out. Example only.
Draft-and-approve replies
A reply is drafted from your own templates and the customer record, then held for a person to approve before it is sent. Example only.
Record updates between systems
When a job, order or booking changes in one tool, the matching record in another is updated and the change is logged. Example only.
What you get
We work with the tools you already use wherever they have a usable interface. If a tool cannot be connected safely, we say so at the fit call rather than after you have paid.
- 01A written map of the workflow as it runs today, including where it fails.
- 02The workflow built and connected to your existing tools, with custom software only where nothing existing fits.
- 03Testing against named cases, including failures and the point where a person takes over.
- 04A view of outcomes, so you can see what the workflow did and what it left for people.
- 05Documentation and access handed over to you, with any recurring charges explained.
What changes
- One repetitive task runs as a defined workflow instead of depending on someone remembering to do it.
- People approve the steps that matter rather than doing every step by hand.
- You can see what the workflow did with each item and what it left for people.
- The workflow, its documentation and its test cases are yours, so it can be maintained or changed without us.
How it runs
- 20-minute fit call, then a written fixed quote with scope and milestones.
- Workflow map agreed in writing before the build starts.
- Build and testing in your tools, ideally against a test account or sandbox.
- Handover with documentation and access, then a 30-day check-in to review outcomes.
What you supply
- Access to the systems involved, ideally a test account or sandbox.
- Five to ten real, redacted examples of the work, including some that went wrong.
- One named person who can answer questions and approve the finished workflow.
Limits
- One workflow per starter scope. Additional workflows are separate scopes.
- A 30-day check-in after handover is a review, not unlimited development or 24/7 support.
- We do not promise recovered revenue, time saved or a particular AI outcome. We agree what the workflow must do, test that it does it, and show you the results.
- Licences, message costs and usage charges from third-party tools are yours and are stated in the quote.
How it works
- 01
Scope
A 20-minute fit call covers the process, how often it runs, the systems involved, budget and who decides. If the brief is already clear, no paid audit is needed. You get a fixed quote with scope and milestones.
- 02
Build
The workflow is built against your test cases, in your tools where possible, with approval steps wherever a mistake would matter.
- 03
Test
We run the agreed cases, deliberately including failures, and fix what breaks before anything touches live work.
- 04
Hand over
You receive the working workflow, the documentation and the access. We review it with you at 30 days.
How we know the approach holds up
Evidence from our own work
We run the same discipline on our own products. ReplyOS handles real enquiries with human handover, and Slipmark, now open source, exists because we needed to prove our own automated agents were still doing what they were allowed to do after a change. This is internal work, not client results.
See what we build and operateWhere it fits
Many clients find their first workflow through a workshop or diagnostic; once it is live, monitoring keeps it checked, and anything larger becomes a production build.
Questions before you start
How much does an AI automation project cost?
A starter scope covering one workflow is from £2,500, as a fixed quote agreed before work starts. Larger workflows, several workflows or custom software are quoted on their own scope. Third-party licences and usage costs are separate and listed in the quote.
Does it work with the tools we already use?
Usually, yes. We build around your existing tools wherever they offer a usable way to connect. We confirm this at the fit call, before you commit.
What happens to our data?
We only access the systems and data the workflow needs, and we agree that list in writing before work starts. Where personal data is involved, the contract states who processes it and for what. You can ask for the data handling detail before booking a call.
Who owns what you build?
The workflow configuration, documentation and any bespoke code written for you are agreed in the contract, and ownership of bespoke work is stated there. Third-party tools remain under their own licences.
What is the next step?
Describe the process in the contact form. If it looks like a fit, we arrange a 20-minute call, then send a fixed quote. There is no obligation and no proposal deck.
What makes a good first workflow to automate?
A good first workflow runs often, follows steps a person could explain in a few minutes, and causes visible problems when it is missed or done late. It should have clear inputs and a clear finished state. Avoid starting with a process that changes every week or depends on one person's judgement throughout. If you are unsure, bring two or three candidates to the fit call and we will say which is the best place to start.
What if one of our tools has no API?
We tell you at the fit call, before you commit. Some tools without a public API can still be connected through email, exports, webhooks or an integration platform, and we will say whether that route is safe and reliable enough. If a tool cannot be connected safely, we say so plainly and suggest a different scope rather than building something fragile.
Can our own staff maintain the workflow afterwards?
Yes, that is what the handover is for. The documentation is written for the person who will look after the workflow, covering how to pause it, change its settings and rerun the test cases. We walk them through it at handover and review it again at the 30-day check-in. Larger changes later are scoped and quoted separately.
Tell us what needs to work better.
Describe the process and the tools involved. If it looks like a fit we will arrange a 20-minute call.