We automate your processes and keep them running.

It works — as long as one person does it by hand.

Automated. Monitored. Kept alive.

Two ways people arrive here

Common starting points — not client categories.

The process was never automated.

You are the integration layer of your own company: every order, every invoice, every status update passes through your keyboard.
Two systems were bought specifically to talk to each other. A person still copies data between them, at an error rate nobody has measured.
Every exception becomes a chat thread, and every chat thread becomes precedent nobody wrote down.

The process was automated, and now it owns you.

You built it in a no-code tool. It works. You are now the only person who can fix it, and that was not the job you took.
An agency delivered, invoiced and left. The workflow still runs, and nobody can say what it does when a case does not match the happy path.
The Zapier, Make or n8n chains keep breaking, and nobody can say why, or what they actually do.

These are examples, not a closed catalog. If your version has different numbers, they are still numbers: start with those.

How automation actually fails

Automation rarely fails loudly. The expensive failures are the ones that keep running while being wrong. Each of the six below is a design problem, and the section after this one is the design.

Silent failure: The workflow errors and nobody hears. Rows stop syncing on a Tuesday; the business finds out at month-end close.
Drift: An upstream system changed a field or a form; the automation keeps working on assumptions that are no longer true.
No owner: The person who built it left. Nobody can change it, so everybody works around it.
No rollback: A bad batch went out, and there is no procedure to undo it.
Invented data: An AI step fills a gap with a plausible value instead of flagging it. Plausible is worse than blank: blank gets noticed.
Tool sprawl: Six subscriptions, four webhooks, one person who remembers why.

What every build is held to

Seven properties. Where a property leaves an artifact, the artifact is named; where it leaves a rule, the rule is written into the scope.

The reliability contract: seven properties, what each means, and where it lives
Property	What it means	Where it lives
Observable	Every run leaves evidence: what it read, what it decided, what it did.	the run log
Fails loud	Errors surface on a defined escalation path agreed in the scope, never into silence.	the escalation path, in the scope
Bounded	Write access is scoped in the scope document before the build starts, and the automation is configured to that scope.	the scope document
Reversible	Changes the automation makes inside your systems can be undone by a defined procedure. What has already left the building is handled by the exception path, not by a rollback.	the rollback procedure
Operable	Someone on your side can operate, pause and question it.	the runbook
Measured	A baseline on the metric that matters, taken in the diagnostic where the data allows, and the same metric read after.	the baseline, in the diagnostic
Switchable off	Ending the engagement is a procedure, not a crisis: the runtime stops when the agreement ends, and the documentation of the process goes with you.	the process documentation

Every automated decision leaves evidence. When the system cannot decide safely, it says so. No invisible handoffs. No silent guesses.

What the automation decides, and what stays with you

Every workflow gets an autonomy ceiling before it gets code.

Tier 1 — reads and reports: Observes, extracts, summarizes, reconciles. Touches nothing.
Tier 2 — acts through a human gate: Prepares the action: the draft, the entry, the reply. A person approves before anything leaves the building.
Tier 3 — never automated alone: Payments and legally binding steps are executed by a person; the automation prepares and documents them.

The ceiling is set during the diagnostic, written into the agreed scope, and not raised without a written change.

AI reads; rules and people decide

Four mechanisms are available for every build that includes an AI step, and which of them apply is written into the scope: source-anchored extraction, where every extracted field points back to where it came from; a confidence floor, below which the workflow does not decide and queues the case for a person with the reason attached; a shadow run before cutover, where the automation runs alongside the existing process and its output is compared with what people actually did; and a reconciliation window after cutover, where automated output is checked against reality for an agreed period.

The exception path ends with a person, never in silence.

Runs at night. Watched by day.

Work runs during European business hours.

When workflows execute: Whenever their triggers fire, nights and weekends included.
When they are monitored: During European business hours.
When a person can intervene: During European business hours.

Anything that would require a human overnight is treated as a design defect and engineered out: retries, safe fallbacks, queues that wait, human-in-the-loop gates placed at points of business impact.

No 24/7 pager is promised here, because promising one would be the first silent guess.

What should not be automated

Where automation is on the table, the diagnostic says which steps should not be automated and why. If a process should not be automated, that is a finding, not a lost sale.

The volume is too low for the build to ever pay back.
The process changes faster than any automation could keep up with.
The exceptions are the process: automating the happy path would just relabel the work.
The step exists to keep a single person accountable, and that accountability is the point.
A form redesign or a checklist fixes it for a fraction of the cost.

“Set it and forget it” is how a process stays wrong for six months. This list is the first defense against it.

How an engagement runs

A build is not the first step.

Diagnose

Format: A fixed-scope diagnostic across the processes you nominate.
Deliverable: One written diagnostic: what the process actually does, what it costs where the data allows, what to automate and what not to, and, where the case allows, a plan and the recommended tools. The more complete the material you share, the more specific the diagnostic.
Ends with: A decision: proceed, revise the scope, or stop.
Yours to keep: Yours to keep: the entire diagnostic. It is written to be usable with any vendor, not just this one.

Diagnose is a step you can stop at: the artifact is written to be acted on without us — with your own team, or with another vendor. Build is offered as a next step, never assumed.

Build

Format: Fixed scope, fixed fee.
Deliverable: The working automation with its human-in-the-loop controls, audit trail, runbook and handover documentation, deployed where the engagement shape puts it: in your accounts when ordered as development, on infrastructure we operate when run as automation as a service.
Ends with: Acceptance against the agreed scope, and the same decision again: proceed, revise, or stop.

Run

Format: Managed operation during European business hours: monitoring, exception handling, controlled changes. Monthly, and either side can end the engagement on the same terms.
Deliverable: Handled exceptions and a periodic reliability report.

What transfers at the end follows the engagement shape, and it is written down before the work starts. Ordered as development, or brought in as capacity, you keep everything produced — repositories, configuration and documentation, in your accounts, in plain formats. Running as automation as a service, the automation runs on infrastructure this practice owns and operates and stops when the agreement ends; the documentation of the automated process goes with you, so your own people can take the process on. Either side can end the engagement on the same terms.

The runtime is automation infrastructure we operate: reusable components, a separate deployment per client, data processed in isolation. A deliberate choice, and the reason the off-switch is designed first, not last.

How pricing works

This page publishes how engagements are priced, not what they cost. Fixed scope, fixed fee: no hourly billing, no open-ended discovery. The figure depends on how many processes and systems are in scope, and it arrives in writing before anything starts. The only free step is the 30-minute fit call.

Four ways to engage

Engineering work starts with paid, fixed-scope work — a diagnostic, a review or a second opinion.

Start here

Process Diagnostic

Trigger: A manual process eats hours every week, and nobody can name what it costs.
Format: fixed scope, short by design — one written diagnostic; ends with a proceed, revise or stop decision.
What you receive: A process map with volumes and, where the data allows, cost per step · an automate / keep-manual / redesign verdict for the steps in scope · a sequenced automation plan · a risk and exception inventory.
What it is not: Not a tool pitch. Not a license sale. Not a free audit.

Start here

Automation Rescue

Trigger: The Zapier, Make or n8n chains keep breaking, and nobody can say why, or what they actually do.
Format: the review form of Diagnose: a fixed-scope review of the automations you already run; ends with a stabilize-or-rebuild verdict.
What you receive: An inventory of the automations found in the accounts and systems you give access to · a classification of failure modes · a stabilize-or-rebuild verdict per chain · a staged fix plan.
What it is not: Not an automatic rewrite proposal. Not tool advocacy: the verdict can be to keep what already runs.

The bridge

Automation Build

Trigger: The diagnostic verdict is in, and the decision is to proceed.
What you receive: A working automation, deployed where the engagement shape puts it — in your accounts when ordered as development, on infrastructure we operate and isolated per client when run as automation as a service · human-in-the-loop controls and an audit trail · exception handling with named failure modes · a runbook and handover documentation.
What it is not: Not an unattended system: changes are managed, and exceptions land with a human owner.

Where it leads

Run & Reliability

Trigger: The automation is live. The question is no longer how to build it; it is who notices when it drifts.
Format: a standing engagement — monthly, and either side can end it on the same terms.
What you receive: Monitoring during working hours · reliability reporting · a controlled change process · exceptions handled on the path agreed in the scope.
What it is not: Not a 24/7 pager. Not an embedded seat.

What gets measured

The baseline comes first; the menu is picked during the diagnostic:

cycle time per case
touches per case
rework rate
exception rate
time to first response
cost per document processed
duration of month-end close
share of cases that never need a person

Data and access

An NDA before materials are exchanged, by default, with the template available on request. What leaves your perimeter is agreed per engagement, in writing, before access is granted, and access is scoped to what the work needs. Each client's automation runs in its own isolated deployment. When the work ends, access is offboarded by a standard procedure.

Three worked problems

Instead of miracle numbers, here are three worked problems: the shape of the work on a class of problem, including the failure modes most pitches leave out.

From a crowded shared inbox to structured, owned work

Message arrives
Classified
- unreadable or ambiguous → review queue, reason code
- duplicate → merged, flagged, logged
Confidence check
- below threshold → review queue, your decision recorded
Filed in the CRM
- CRM outage → retries, then the exception queue
Owner assigned

The boxes are the happy path; the exits leave under the step where they happen, and every one of them lands with a person or in a queue, never in silence.

The pain

A shared inbox — sales@, info@, ops@ — is where requests arrive and where they quietly disappear. Every message is read by a person, sorted by a person, re-typed into the CRM by a person. Or it isn't, and nobody can say which.

The metrics that hurt

first-response time, swinging from minutes to days depending on who is watching the inbox
re-keying time on sorting and manual entry
duplicate and orphaned records: the same request entered twice, or owned by no one

The approach

Deterministic where possible, model-assisted where needed: routing rules handle the predictable majority, classification handles the long tail. Rules are auditable; models are measured.
Confidence thresholds decide what gets filed automatically. Everything below threshold goes to a review queue, handled by the owner agreed in the scope.
Every extracted field links back to the source message: any record can answer what was read, what was decided, and why.
Failure modes are designed before launch, not discovered after: unreadable messages, ambiguous intent, duplicates and a CRM outage have defined paths.
The mailbox stays and the CRM stays: the pipeline connects them wherever they expose a usable interface, instead of replacing them.

Failure modes designed in

Ambiguous or unreadable message: Review queue, with a reason code
Duplicate request: Merged, flagged, logged
CRM or API outage: Automatic retries, then the exception queue
Classification below threshold: Your team decides; the system records the decision

What you get

A working pipeline connected to the mailbox and CRM you already run
A review queue for the messages automation should not decide alone
An audit trail for every message the pipeline handles: classification, extracted fields, action taken, approver
A failure-mode map and runbook: what happens when parsing fails, the CRM is down, or a duplicate appears
A baseline: first-response time, share auto-filed, touches per message, so before and after is a fact, not an impression

Typical shape: a fixed-scope build on your existing mailbox and CRM, with the hardening period agreed in the scope.

Deliberately left out: replacing the CRM, and replying to customers without a person. Drafts are prepared; a person sends.

From PDF invoices to reconciled records, with every exception accounted for

Document arrives
Fields extracted
- unreadable scan → exception queue, correction requested
- duplicate invoice → held for review, logged
Matched to order and delivery
- unknown vendor → held for approval
- outside tolerance, currency or VAT anomaly → approver, reason code
Posting prepared
Released by a person

The boxes are the happy path; the exits leave under the step where they happen, and every one of them lands with a person or in a queue, never in silence.

The pain

Invoices, delivery notes and credit notes arrive as PDFs in a mailbox, files in a folder, downloads from a portal. Someone re-keys them into the accounting system. Mismatches between order, delivery and invoice surface at month-end, when they are most expensive to untangle.

The metrics that hurt

touch time per document
exception rate: the share of documents that do not match cleanly and stall
days-to-close: month-end stretched by unresolved mismatches
duplicate payments and late-payment penalties: the failures that cost real money

The approach

Extraction with per-field confidence: every value stays linked to the region of the source document it came from.
Reconciliation is deterministic: documented tolerances, explicit match logic against orders and deliveries. Models read documents; rules decide postings.
Postings are prepared by the automation; a person releases them, and anything outside tolerance routes to the approver with a reason code.
Unreadable scans, unknown vendors, currency and VAT anomalies, duplicate invoices: each lands in the exception queue.

Failure modes designed in

Unreadable scan: Exception queue; correction requested at the source
Unknown vendor: Held for approval — never auto-created, never auto-paid
Currency or VAT anomaly: Flagged with a reason code, routed to the approver
Duplicate invoice: Checked against posting history, held for review, logged

What you get

An intake-to-posting pipeline wired into your existing accounting stack
The tolerances and match logic, written down, with who may override them
An exception queue with reason codes
A document-level audit trail: source document, extracted values, match result, approver
A baseline: touch time per document, exception rate, days-to-close

Typical shape: a fixed-scope build against your accounting stack, with the parallel run before cutover agreed in the scope.

Deliberately left out: automatic payment release, and vendor onboarding without a person.

Follow-up chains that stop on a reply and never let work age out silently

Item enters the sequence
Reality check
- reply, closed deal or opt-out → exit, logged with the trigger
- touch limit reached → escalates to the owner
Draft prepared
Approved by a person
Sent and logged
- bounce or send failure → flagged, suppressed, owner notified

The boxes are the happy path; the exits leave under the step where they happen, and every one of them lands with a person or in a queue, never in silence.

The pain

In property businesses, the pipeline runs on threads that die quietly: a viewing request answered once and never chased, a rental application stalled on documents nobody re-requested, an offer that expired while the follow-up lived in someone's head. The same pattern runs through any pipeline built on quotes and applications.

The metrics that hurt

time-to-follow-up
share of enquiries with a second touch
stale-item ratio: viewings, applications and deals technically open, practically dead
enquiry-to-decision time, stretched by every follow-up that did not happen

The approach

The core is a state machine, not a model: explicit stages, intervals, stop conditions. Predictable enough to audit, boring enough to rely on.
A reality check runs before every send: a reply, a closed deal or an opt-out exits the sequence and logs why.
External messages go out only after a person approves the draft: your name, your tone, your final say. Internal nudges run automatically.
Loops end: after a set number of touches the item escalates to its owner for a decision — park, close, or reach out personally.
Sends are scheduled inside working hours by default; the schedule is a setting agreed in the scope, and every touch is logged with its rationale.

Failure modes designed in

Reply arrives mid-sequence: Immediate exit, logged with the trigger
Bounce or send failure: Flag, suppress, notify the owner
Opt-out: Permanent suppression list, logged
Escalation ignored: Stays visible in the aging list — surfaced, not lost

What you get

A follow-up engine on top of your CRM, mailbox or task tracker, not another tool to adopt
Sequence definitions with explicit stop and suppression rules
An approval queue for external drafts: tone and final say stay with your team
Escalation rules: after a set number of touches, a person decides, not a loop
A log of every touch with its rationale
An aging list: what is due, what is stale, what needs a person

Typical shape: a fixed-scope build on your existing pipeline data, with any tuning period agreed in the scope.

Deliberately left out: messages sent without approval, and sequences with no end.

If your problem is actually a different page

This page is about your business processes. If the problem is your software team's own AI-driven development, code arriving faster than it can be reviewed, that is a different page: Controlled AI Delivery
If the workflows are sound but the platform under them is not, deployments, environments, incidents, cloud cost, start here: Cloud Infrastructure & DevOps

Fit

The diagnostic exists to decide whether we are the right answer at all.

The 30-minute fit call is free, booked after your email is read. Write the numbers if you have them: how many cases per week, how long each takes today, what breaks and how you find out. They are the beginning of your baseline.

How engagements work

FAQ

Can we do this without AI agents?: Yes. If you want the work built without AI agents, we build it that way — deliberately, and agreed as such before anything starts. What changes is the shape of the engagement, not the standard it is held to. Without agents, the work is contracted as custom development rather than as managed automation, and it has to cover every discipline the work touches, engineering and non-engineering, on that footing from the start. So the scope is agreed on that footing before anything starts, rather than adapted halfway through. The quality standards do not move. A person reviews the work before it reaches production. CI and quality automation stay in place: linters, static checks, security checks. The difference is a deterministic approach instead of agents in the loop.
How do you work if we have no engineer of our own?: Yes, we take that work. It does mean one thing has to be settled before anything starts: a concrete zone of responsibility, written down — what we own, what stays with you, and who decides what. Without that line the work ends up leaning on whoever on your side happens to be nearest to it, with no mandate for it, and ownership of the result gets contested later. You are not expected to supply technical judgment. Decisions are written down as the work proceeds, with the reasoning behind them, so what was decided and why sits in the record rather than in someone's head.
What happens when it breaks at night?: Execution is continuous; monitoring and intervention happen during European business hours. Anything that would require a human overnight is treated as a design defect and engineered out: retries, safe fallbacks, queues that wait, human-in-the-loop gates placed at points of business impact. No 24/7 pager is promised here, because promising one would be the first silent guess.
What do we keep if we stop?: What transfers at the end follows the engagement shape, and it is written down before the work starts. Ordered as development, or brought in as capacity, you keep everything produced — repositories, configuration and documentation, in your accounts, in plain formats. Running as automation as a service, the automation runs on infrastructure this practice owns and operates and stops when the agreement ends; the documentation of the automated process goes with you, so your own people can take the process on. Either side can end the engagement on the same terms.

One more thing

Does the work stop when the one person who does it is away?

A vague request is fine. "Not sure if this is your thing" is enough to start.

Every email gets a reply within working hours.