Automation is not the goal. A reliable operation is. Running a process faster without designing it first simply loses the same work sooner, with fewer people watching.
The Quiet Protocol designs the operating workflow, then configures the platforms you already own, connects them, and automates the steps that can run without a person each time. Judgement stays human. Every automated path gets a named owner and a defined behaviour for the moment it cannot complete.
Recognise the operation
If several of these describe a normal week, the problem is not that you lack tools. It is that no agreed path runs through them.
None of these is a software problem exactly. The business usually owns capable tools. What is missing is an agreed path through them: a record that everyone trusts, an owner at every step, and a defined answer for the moments when something does not go as planned.
The position
Automation is not the goal. A reliable operation is. Automating a process that was never designed simply makes an unreliable operation run faster, with fewer people watching it. The work that matters happens before anything is automated: deciding how the process should actually run, which record is authoritative, who owns each step, and what is supposed to happen when something goes wrong.
We describe how the work should run, stage by stage, with the conditions to advance, the owner at each point and the exceptions that actually occur. That description is short, and it is the thing that gets agreed. Everything after it is implementation.
For every kind of information the process touches, one system becomes the owner and the rest hold references. This single decision removes most reconciliation work, and skipping it is why so many automation projects produce new disagreements instead of fewer.
Repetitive, rule-clear, stable steps get automated. Steps that need judgement keep a person, with better information in front of them. The measure of a good design is not how much got automated, but how little of the remaining human work is wasted.
Every automated step is given a defined behaviour for the case where it cannot complete: who is told, what queues, what escalates, what must never pass silently. This is the part that separates an operation you can rely on from one that quietly loses things faster.
These are layers of one answer, not a menu. A typical engagement uses four or five of them. The skill is choosing the least amount of machinery that makes the process reliable.
The distinction
Four different answers that get confused with each other, usually because a supplier only sells one of them. They solve different problems and cost different amounts.
Can the software already do this?
The platform can hold the process. It was set up once, at purchase, and never matched to how the work actually runs.
Do the systems work, but not together?
Each platform does its own job. The losses happen at the handoffs, where a person carries information from one screen to another.
Can this step run reliably without a person each time?
The process is stable and repetitive, the rules can be written down, and the consequence of an occasional error is manageable and recoverable.
Is there anywhere for this process to live?
The workflow is strategically important and genuinely specific, and no available platform can hold it without material compromise.
This one is not ours to sell here. Custom software development
We work through these in order and stop at the first one that makes the process reliable. This page owns the first three. When the answer really is the fourth, it belongs on the custom software page, and we will say so rather than stretching an automation engagement to cover it.
Step by step
The same nine steps as they usually run, as they run once designed, and, most importantly, what happens on the day something goes wrong.
One new enquiry, from arrival to a booked next step.
How it runs now
This is the shape most operations are actually in. Nothing here is anyone's fault, and every step was a reasonable decision at the time.
Every person in this trace is competent. The process is what is unreliable.
How it runs designed
The same enquiry after the workflow has been designed and the layers applied. Two steps still belong to a person, deliberately.
Fewer steps have a person in them. The steps that still do are the ones worth a person's time.
When it goes wrong
A designed operation is judged on its bad days. These are the behaviours we specify before anything is switched on.
Every one of these is decided in design and tested before launch, because this is where trust in a system is won or lost.
Judgement
Asked per step rather than per process, which is why a well-designed workflow usually ends up part automated and part human rather than one or the other.
High frequency, clear rules, stable process, low judgement, recoverable failure
These are the steps worth taking off people entirely: routing, reminders, record updates, scheduled actions, requests and receipts. They still get monitoring and a defined failure behaviour, but nobody needs to watch them run.
High frequency and clear rules, but the outcome is hard to reverse
The system does everything up to the decision, assembles the context and presents it. A person approves or declines, and that approval is recorded. Most of the time saved comes from the preparation rather than the decision.
Real judgement required, but surrounded by administrative drag
The decision stays with a person. The work around it does not: finding the file, assembling the history, writing the record afterwards, telling the next person. Often the largest and most welcome improvement available.
Unstable process, unclear rules, high exception rate, or the step should not exist
Some steps only exist because something upstream is broken. Automating them preserves the fault and makes it harder to see. The honest recommendation here is to fix or remove the step, then revisit it.
| Dimension | What we ask | Points to automation | Points to a person |
|---|---|---|---|
| Frequency | How often does this step run? | Daily or many times a week, so the work compounds. | A few times a year. The automation would rot before it repaid the effort. |
| Process stability | How settled is the way it runs? | It has worked this way for a long time and is not being redesigned. | It is actively changing. Settle it before encoding it. |
| Rule clarity | Can the decision be written down? | Yes, completely, including the edge cases. | It depends on context a rule cannot capture. |
| Exception rate | How often is it not the normal case? | Rarely, and the exceptions are themselves predictable. | Often, and each one is different. |
| Consequence of failure | What happens if it goes wrong? | Noticed quickly and cheaply corrected. | Money moves, a commitment is made, or somebody is harmed. |
| Judgement required | Is there a real decision in it? | No. It is applying a known rule to known information. | Yes. Experience, negotiation or care is what makes it right. |
| Data availability | Is the information there and trustworthy? | Yes, in a system, structured and current. | It lives in people's heads or in inconsistent free text. |
| System access | Can the software reach what it needs? | Documented interfaces and permissions that can be granted. | No usable interface, or access that cannot be given safely. |
| Business importance | Does doing this well matter? | It affects capacity, cost, response time or the customer's experience. | It is minor. Automating it is effort spent for tidiness. |
Two dimensions decide most cases: how much judgement a step needs, and how often it runs. The rest adjust the answer. We apply this per step rather than per process, which is why a well-designed workflow usually ends up part automated and part human rather than one or the other.
Coverage
Organised by the business system they belong to. Most engagements take one of these and do it properly rather than touching several at once.
Everything between a person making contact and the business being ready to act.
The stretch that most often decides whether a new client feels well handled.
The daily running of work: who does what next, and what happens when it stops.
Making the customer record something the business can actually run on.
Getting documents out of inboxes and into a process that can see them.
Ending the reconciliation job and making operational state visible.
The connective work that makes several platforms behave like one.
A layer inside the workflow, not a replacement for it.
These describe the kinds of process work we do. They are categories of engagement, not a claim that each has been delivered for a named client. Where we can point to specific documented work, we name it.
Human control
It is easy to automate the path where everything goes to plan. That path is a small share of real operating life, and it is not where trust is earned. We design the operation around what happens when something goes wrong, because that is what people judge a system by.
Every automated path is specified with its failure case. What happens when the information is missing, the system is down, the reply never comes, or the input is not what the rule expected. These are decided in design, not discovered in production.
Waiting is not a state a process should be able to stay in forever. Each waiting step has a limit and a destination: who hears about it, after how long, and what they are expected to do.
Anything that commits the business keeps a person on it, and the approval is recorded: who, when, and on what information. An approval nobody can later evidence is not a control.
The record shows what happened and why, including what the automation did on its own. When somebody asks why a customer received something, the answer should be retrievable rather than reconstructed.
Every item has a current owner and every automated path has a responsible person. Work that belongs to the system in general belongs to nobody in particular.
When automation cannot run, the process degrades to something a person can operate rather than stopping dead. Reverting to manual should be a known procedure, not an emergency.
Kept deliberately where experience, negotiation or care is what makes the outcome right. The system's job at those moments is to make the person fast and well informed, not to replace them.
Delivery
Eight stages, each producing something you can read and disagree with before the next one starts.
How the process runs now, where it breaks, what the breaks cost, and what has already been tried. Deliberately short, and scoped to reach a decision rather than to produce a report.
ProducesA stated problem and a recommended mode: configure, integrate, automate or build.
The designed workflow: stages, conditions, owners, the system of record for each entity, the exceptions and the escalations. Written plainly enough that the people who run the work can correct it.
ProducesAn agreed workflow definition and acceptance criteria.
What runs where, what stays, what connects, and what the failure behaviour of each dependency is. Decided before implementation, because these are the expensive choices to revisit.
ProducesA named architecture and an integration boundary.
Setting up the platforms to match the agreed process and connecting them, with ownership settled, errors handled and monitoring in place.
ProducesPlatforms configured and connected, with monitoring.
Triggers, routing, reminders, scheduling, document handling and any AI-assisted steps, built to the definition and instrumented from the start.
ProducesThe automated workflow running in a test environment.
The normal path, then the awkward ones on purpose: missing information, unavailable systems, absent owners, ambiguous inputs. We test the bad days before launch.
ProducesTested behaviour for the normal and exception paths.
A deliberate cutover with a documented fallback, and training built around the jobs people do rather than a tour of the features.
ProducesA live workflow, a trained team, and a way back.
Monitoring, failure investigation, maintaining connections as platforms change, and improving the workflow against agreed measures.
ProducesA running operation with named responsibility.
Diagnosis is scoped to reach a decision and define the right workflow. It is part of the engagement rather than a free strategy exercise, and it does not run open-ended. We look far enough to build the right thing.
Architecture
Every additional connection, automation and custom component is something that has to keep working. The right design is the smallest one that makes the process dependable, not the most capable one available.
We do not replace a platform because it is old or because we would have chosen differently. Replacement is a decision with its own cost and needs its own justification.
A single engagement might configure your CRM, connect it to two other platforms, automate six steps, add one AI-assisted step and build one small component. That mixture is normal and is chosen deliberately.
If a piece of the operation can only be maintained by us, that is a risk we have created. Automations are documented, named and explainable to the people who depend on them.
Businesses change. A workflow that can only be altered by rebuilding it was designed badly. Change paths are part of the design rather than a later problem.
Where the answer sits elsewhere:
Evidence
Three engagements where the work and the counts are documented. Each began with a process that people were holding together, and each used a different mixture of configuration, integration and automation.
Configure and automate
A commercial lines agency in Atlanta with 18 producers, already licensing a well-known CRM.
Some producers used the CRM. Others kept spreadsheets and Outlook folders, because the default setup did not match how a renewal or a coverage gap actually needed to be tracked. Management could not trust its own pipeline report.
Integrate and automate
A Texas disaster restoration firm running 6 crews and 3 estimators through a group chat and a whiteboard.
During flood and hail season crews doubled up on the same job while others sat unassigned, estimators drove to sites already covered, and insurance paperwork slipped behind.
Configure, integrate and automate
An accounting firm that moved from having a website to operating a digital client experience.
Scheduling, intake and client communication ran on manual back-and-forth across four calendars.
The figures above are counts and stated facts from those engagements, linked to the full records. We do not publish projected savings or modelled returns on this page.
Questions
Business process automation is the practice of designing how a business process should run, then using configuration, integration, automation and where necessary custom software so that it runs that way reliably without a person carrying it. The automation is the last part. The design decisions, which record is authoritative, who owns each step and what happens when something fails, are what make it work.
An agreed workflow definition, the platforms configured and connected to match it, the automated steps built and instrumented, tested exception handling, a trained team, and ongoing responsibility for keeping it running. The deliverable is a working operation rather than a set of recommendations.
Software gives a team the ability to build workflows. It does not decide which process to fix, which system should own which record, where a person should stay in the loop, or what should happen when a step fails. That design work is the service, and it is the part that determines whether the software helps.
Only where replacement is genuinely justified, and it is named explicitly in scope before anything changes. Most engagements keep the existing platforms and make them work together. A tool that does its job well is an asset, not a problem to be solved.
Per step rather than per process, against frequency, process stability, rule clarity, exception rate, consequence of failure, judgement required, data availability, system access and business importance. High frequency with clear rules and low judgement is a strong candidate. Real judgement, or a failure that is expensive and hard to notice, keeps a person.
Whatever was specified in design. Each automated path has a defined failure behaviour: what retries, what queues, who is alerted, what escalates after how long, and what must never pass silently. A step that cannot complete either waits visibly or hands over to a named person. It does not proceed on a guess.
Not necessarily. AI is one layer, used where language and variation defeat written rules: classifying, extracting, summarising, drafting and retrieval. Routing on stated criteria, calculations and record-keeping should stay deterministic. Many valuable automation engagements contain no AI at all.
The sequence matters more than a published number, and we will not quote a timeline that suits a marketing page rather than your process. We scope the first release to one valuable path, end to end, so a real part of the operation improves before the wider workflow is finished.
No. Describing how the work actually runs is the first part of the engagement, and the version people describe is usually different from the version that was written down. What does help is agreement on how it should run, because building while that is still being argued is the most expensive way to proceed.
When the workflow is strategically important and genuinely specific to your business, and no available platform can hold it without material compromise. That is a different engagement with different economics, and it is set out on the custom software development page.
Not a brief, and not a list of tools. Walk us through one process that needs people to hold it together: where it starts, who touches it, where it stalls, and what it costs when it does.
We will tell you whether it needs configuration, connection, automation or a build, and which of those you can do without. If the answer is that the process needs agreeing before anything is automated, we will say that too.
Talk through the system