The dream is a system that just runs. The reality, for most small firms, is a system that runs fine on Tuesday and silently falls over on Thursday, and nobody notices until a customer rings to ask where their thing is. The gap between those two outcomes is not smarter software. Its loop engineering: deciding in advance what the system handles alone, what it hands to you, and what it shouts about.
What a loop actually is
A loop is any repeating job your business does: chasing an unpaid invoice, booking a reminder, pulling a document and filing it, sending a follow-up after a quote. Right now, a person probably does it, or it doesnt get done consistently. Automation can take the repetition. But a loop with no exit condition and no human checkpoint is not a system - its a liability.
The question to ask about any loop before you build it: what does “wrong” look like, and who finds out? If you cannot answer that, the loop is not ready to run unsupervised.
The three-layer model
Every loop we build sits in one of three layers. This is not a technical taxonomy - its a question about risk and reversibility.
- Layer 1 - Run and log. Low-stakes, fully reversible, high volume. The system acts, writes a record, and you review the log when you want to. Example: filing an inbound document into the right folder, or sending a standard acknowledgement email. If it goes wrong, nothing is lost - you correct the record and move on.
- Layer 2 - Run and flag. Medium stakes, partially reversible. The system acts, then immediately raises a flag, a short message to a Slack channel or an email thread, a one-line note that says what it did and why. You only respond if something looks off. Example: a quote follow-up sent three days after no reply. The email goes out; you see the log line; you intervene if the customer had already called. Most day-to-day automation lives here.
- Layer 3 - Pause and ask. High stakes, hard to reverse. The system stops, presents the decision to a human in plain language, and waits. Example: anything touching money, a cancellation, a contract, a message that the system has classified as a complaint. The loop does not continue until a person says go.
The mistake most people make is building everything as Layer 1 because it feels efficient. The mistake we see next most often is building everything as Layer 3 because it feels safe. Neither works. Layer 1 on a high-stakes action means you find out about the error from a customer. Layer 3 on a filing task means the human is doing the automation’s job.
The worked example: a quote follow-up loop
Say you send ten quotes a week. On average, three need a follow-up before the customer replies. A person spending five minutes per follow-up, finding the quote, drafting the message, logging the outcome: that is fifteen minutes a week, which sounds fine until you count the ones that slip through because it was a busy Friday.
Run that arithmetic on your own numbers: quotes per week, times the percentage that need chasing, times the minutes per chase, times your rough hourly rate for that person’s time. Then add the value of the quotes that went cold because nobody chased. That second number is usually bigger than the first.
A Layer 2 loop handles this cleanly. The system watches for quotes with no reply after 72 hours, sends a short personalised follow-up from the owner’s email address, logs the send, and posts a one-liner to a nominated channel: “Follow-up sent to J. Harrison re: kitchen refit quote, 4 Oct.” You glance at it. If Harrison rang yesterday and you forgot to mark the quote closed, you send a quick apology and close it manually. That happens once a month. The other nine follow-ups ran without you touching them.
The loop earns its keep not by being clever, but by being consistent. It does not have a busy Friday.
The thing that kills loops: silent failure
A loop that stops working and tells nobody is worse than no loop at all, because you think the job is being done. Build a dead-man’s switch, a heartbeat check, into anything that matters: a daily message to a nominated channel that says “loop ran, N items processed” - and if that message does not arrive, you know to look. Some platforms call this a health check or a monitor; the name doesnt matter. What matters is that silence is never the success state.
The same logic applies to the human checkpoint in a Layer 3 loop. If the system is waiting for approval and nobody responds, the loop needs a timeout and an escalation - not an infinite wait that blocks the job downstream.
Before you build anything
Walk the job by hand once, slowly, and write down every decision point. Not the happy path - the awkward ones. The customer who replies in Welsh. The invoice where the amount is blank. The booking request that comes in at 11 pm on a Sunday. Each of those is a fork in the loop, and each fork needs a layer assignment before a single line of automation is written. That exercise, done properly, takes an hour. Skipping it costs you a Thursday.
If you want a second pair of eyes on a loop you are thinking about building - what layer each step belongs in, where the exits should be, whether it is worth automating at all - we are happy to map it with you. Bring the job description and we will tell you honestly whether a loop saves you money or just moves the problem.
