Service · Workflow automation

Workflow automation that moves work between the tools you already run

Enquiries arrive at all hours and sit unread until someone senior has time. The system reads each one, classifies it, logs it, and drafts a reply for a person to approve. Nothing is sent without that approval.

The problem

The work is not the task. The handoffs are.

Enquiries arrive by email, web form, phone and whatever messaging app a client prefers. Someone reads them, decides what they are, copies the details into a CRM or a spreadsheet, tells the right person, and drafts a reply. None of those steps is hard. Together they are most of a morning.

The failure is rarely dramatic. It is an enquiry that sat unread until it went cold, a record nobody logged, or a follow-up that depended on one person remembering.

Fit

Who this is for.

Service businesses taking enquiries across more than one channel, where the first response has to be right rather than instant, and where a person currently does the sorting. Usually between five and fifty people.

Not a fit if your volume is low enough that one person handles it comfortably, or if the process changes every week. Automating an unsettled process just makes the churn faster.

In practice

What gets built.

Classified intake

Each enquiry is read and tagged by type, urgency and client tier, so the queue is ordered by something other than arrival time.

A structured log

A matter or lead record your team can read without training, rather than a thread someone has to reconstruct.

A drafted reply, queued

Written and waiting for approval. A person edits and sends; the system does not.

Notification and audit trail

The right person is told in Slack or email, and the decision history is kept.

Deliverables

What you get.

  • Classification of each enquiry by type, urgency and client tier
  • A structured matter or lead log your team can read without training
  • A drafted reply per enquiry, queued for approval rather than auto-sent
  • Team notification in Slack or email, with the audit trail kept
  • Escalation rules covering what a person must see
  • Documentation written for handover

Design decision

Why it drafts instead of sends

A slow reply costs you less than a wrong one sent under your name. So the system does the sorting, the logging and the drafting, and stops. A person approves. That boundary is enforced in the workflow rather than left to configuration, which is what makes it safe to run on live client enquiries.

Integrations

What we have built against.

n8n for the orchestration, drawing on a library of over 4,700 mapped workflow patterns, plus email and web forms as intake, Slack or email for notification, spreadsheets as a structured log, and CRM write-back where the CRM has an API. If your stack includes something we have not worked with, we will say so before quoting.

Delivery

How the build runs.

Discovery

We follow a real enquiry through your current process and find where it stalls.

Mapping

Categories, urgency rules and escalation paths agreed in writing before anything is built.

Build

One intake workflow, with the approval gate and the audit trail.

Handover

Your team runs it, adjusts the rules and reads the log without us.

Scope
One intake workflow, fixed
Typical timeline
2 to 4 weeks
Ongoing
Retainer, optional
Ownership
Yours, documented

Timelines depend on how many channels feed the intake and how settled the categories are. Ongoing work runs as Integration Cover: a monthly block of 10, 20 or 40 engineering hours on a three-month minimum, with overflow agreed in advance at the tier rate.

Oversight

Data handling, and what happens when something is wrong.

  • Replies are drafted and queued, never auto-sent
  • Classification is visible on the record and editable by your team
  • Anything outside the agreed categories is routed to a person
  • Client data goes only where you already send it
  • The decision history is kept, so a bad outcome can be traced

Proof

Open it before you talk to us.

This system's public proof is a demonstration scenario rather than a client case study. The intake work we have delivered sits under client confidentiality, so we would rather show you a system you can drive yourself than describe one you cannot check.

Questions

What buyers ask.

Will it send anything to a client without us seeing it?

No. Replies are drafted and queued for a person to approve. Approval-first is the design, not a setting that can be switched off by accident.

What happens when it classifies something wrongly?

The classification is visible on the record and editable, and the reply is still waiting for approval, so a wrong tag is corrected before anything leaves. Recurring mistakes are usually a rules change rather than a rebuild.

Which tools does it need?

Whatever you already run. The system is built around your existing intake channels, your CRM or spreadsheet, and your team's chat tool. We do not ask you to move to a new stack to make it work.

Do you need access to our CRM?

Only where you want records written back to it, and only through its API with credentials you control and can revoke. If you would rather start with a spreadsheet or a shared log, that works too.

What happens to an enquiry that does not fit any category?

It is routed to a person rather than forced into a category. Deciding what counts as unusual is part of discovery, because the escalation rules matter more than the classifier.

Who owns and runs it afterwards?

You do. The handover includes documentation written for your team, and you can keep us on for changes without being dependent on it.

Bring us the process, not the tool.

Tell us what arrives, where it goes, and who currently moves it. If the honest answer is that your volume does not justify a system yet, we will say so.

Back to all four systems · About the studio