We install systems
that own work.
Three things worth knowing: how an engagement runs, what we install from, and what we refuse to build.
The Install Path
Six stages, always in this order. Nothing is built before the opportunity is proven, and nothing runs unsupervised before it has been piloted.
- 01
Opportunity Audit
We map how work actually moves through the business and mark what an agent should own.
You getA ranked map: automate, agentify, redesign or keep human.
- 02
System Blueprint
We design the agent, its tools, its decision boundaries and its escalation rules.
You getA build spec precise enough to be held to.
- 03
Build Sprint
We build against your real data and your real tools, not a demo environment.
You getA working system connected to your actual stack.
- 04
Pilot
The system runs on live work with a human reviewing every output.
You getEvidence of behaviour before you are asked to trust it.
- 05
Deploy
Autonomy is turned up to the agreed level and monitoring switches on.
You getA live system with visible handover points.
- 06
Improve
Escalations and corrections feed back into the system on a cycle.
You getA system that sharpens instead of drifting.
The Install Kit
Every install draws from the same internal library. It is why builds start ahead, behave predictably and hand over cleanly.
Internal build assets, described as capability. No client deployment is claimed by anything on this list.
- KIT/INFRA
Deploy Blueprints
Infrastructure-as-code install scripts. The base of every install is versioned and repeatable, not rebuilt by hand.
- KIT/DATA
Schema Packs
Pipeline and conversation data models. Enquiries, threads and bookings land in a defined shape from the first day.
- KIT/FLOW
Flow Modules
Pre-built n8n sub-workflows: WhatsApp 24-hour window handling, media-type routing, voice-agent webhook contracts, booking triggers.
- KIT/HANDOFF
Escalation Rails
Named-human handoff patterns. Every flow knows who it escalates to and what context travels with the handoff.
- KIT/OPS
Runbooks
Operational docs embedded in every install. What the system does, what to check, and what to do when something looks wrong.
We install on ourselves first.
Order Operations Panel
Built for our own publishing operation. Not a client engagement, and nothing here is presented as one.
Orders lived in a spreadsheet. Stock remaining, dispatch performance and stuck shipments were invisible until someone checked by hand. There was no answer to “did that order ship?” without opening the sheet and counting.
A live operations panel reading the same spreadsheet the team already uses. No migration, no new tool to learn. On demand it computes stock remaining against the current print run, dispatch performance against the agreed window, and a chase-list of anything stuck.
Orders Sheet
the team's existing record
Workflow Layer
reads, derives, counts
Live Panel
answers on demand
source unreachable → panel reports it
How it is built
Dates, not labels
Dispatch state is derived from recorded dates, never a status column. Labels get renamed; dates don't.
Counted, not estimated
Every number on the panel traces to a recorded event. Nothing is projected.
Honest failure
If the source is unreachable the panel says so, instead of presenting stale numbers as live.
Exceptions surface themselves
Anything waiting past the dispatch window or stuck in transit is listed by name to be chased.
- Stock remaining
- —— / ——
- Within dispatch window
- ——%
- Awaiting dispatch
- ——
- Stuck in transit
- ——
against print run
derived from dates
listed by name
chase-list
Source reachable · counted at request time
Sample values. Illustrates the shape of the readout, not our figures.
The same discipline installs on patient recalls, bookings, and enquiry handling.
What we don't do
No dashboards you have to remember.
No tools without owners.
No AI theatre.