Launch in Days, Not Weeks
Professional one-page website. Only a few slots left this month
Your SOPs already describe what should happen, when, and how. That covers most of an automation specification. The missing piece is structuring them so an AI system or automation platform can actually execute the steps, or at least flag when a step needs a human. This is the practical bridge between SOPs and AI: how to convert documentation you already own into working automation.
A well-written SOP contains four things every automation needs: a trigger (what starts the process), conditions (the rules that decide what happens next), actions (the steps taken), and exceptions (what happens when something doesn’t fit the normal path).
That’s not a coincidence. SOPs and automation specs are solving the same problem, consistent, repeatable output regardless of who or what is doing the work. The Toyota Production System, which pioneered standard work as a manufacturing discipline, treats standardisation as the precondition for improvement: you can’t automate or optimise a process until you’ve first written down exactly what “correct” looks like. The same logic applies to a services business chasing invoices or onboarding clients.
The problem is most SOPs are written for humans reading top to bottom, with implicit judgment calls baked in (“use your discretion here”, “check with Sarah if unsure”). AI and automation tools need those judgment calls made explicit. That’s the 20% of work standing between your documentation folder and a working automation.
Four changes turn a human-readable SOP into something an automation platform or AI agent can actually follow.
Write if/then logic instead of prose. “Follow up with the client if they haven’t responded” becomes “IF no response within 3 business days, THEN send follow-up email template B.” The second version has an explicit trigger and a measurable condition; the first requires interpretation.
Define inputs and outputs per step. Every step should state what it needs before it can run and what it produces when it’s done. “Prepare the contract” is not automatable. “Input: client name, service tier, start date from CRM. Output: populated contract PDF” is.
Make decision criteria explicit. Replace “use judgment” with the actual criteria a competent person would use. If your team says “it depends” when explaining a step, that’s the exact point where the SOP needs more detail before it can be automated.
Set measurable completion criteria. “Onboarding is done” is vague. “Onboarding is complete when: contract signed, welcome email sent, kickoff call booked, and CRM status updated to Active” gives automation something concrete to check.
This structuring work is the same discipline behind good workflow mapping, if you haven’t mapped the process properly yet, start there before attempting to automate it.
Once an SOP is structured this way, go through it step by step and tag each one into three buckets.
Fully automatable. Rule-based, data is accessible, no judgment required. Example: “update CRM status when contract is signed”, clear trigger, clear action, no ambiguity.
AI-assisted. The step involves judgment or unstructured input, but AI can draft, summarise, or flag rather than decide outright. Example: “review the client’s brief and identify project risks”, an AI can surface likely risks from the brief text, but a human signs off.
Human-only. Relationship-sensitive, high-stakes, or genuinely novel each time. Example: “negotiate final contract terms.” Leave these alone. Trying to force automation onto judgment-heavy steps is one of the most common reasons AI automation projects fail to deliver the ROI they promised.
Mapping example:
| SOP Column | Automation Component |
|---|---|
| Trigger (“new enquiry received”) | Webhook / form submission event |
| Condition (“if service = X and budget > £Y”) | Decision logic / routing rule |
| Action (“send proposal template”) | Document generation + email send |
| Exception (“if no reply in 5 days”) | Scheduled follow-up trigger |
| Judgment (“assess fit”) | AI-assisted flag for human review |
Once tagged, the “AI-assisted” bucket is where most of the near-term value sits for SMB teams. Rather than a static checklist someone ticks through manually, an AI system can read the structured SOP and actively guide or execute each step, essentially an intelligent checklist that does the work rather than just tracking it.
Tools like Scribe and Tango already capture process steps automatically as someone works, which is a fast way to generate a first-draft SOP. Notion AI and similar tools can then help restructure that draft into the if/then format above. None of these tools automate the process themselves, they get you to a well-structured SOP faster, which is the prerequisite for the automation work.
The gap between “AI helped write the SOP” and “AI executes the SOP” is real and worth being honest about. Writing a clean procedure is a content problem. Executing it reliably against your CRM, invoicing tool, and inbox is an integration problem, and that’s usually where DIY automation attempts stall.
SOPs and automations drift apart if you don’t maintain the link between them deliberately. Two rules keep them in sync:
When automation uncovers an SOP gap, update the SOP first. If your automation hits an edge case the documentation didn’t cover, that’s a sign the SOP was incomplete, not just the automation. Fix the source document, then fix the automation.
When the SOP changes, update the automation in the same sprint. A pricing change, a new service tier, a revised approval chain, if the written procedure changes and the automation doesn’t, you now have two sources of truth that disagree. This is the single most common cause of “automation that used to work.”
Treat SOPs as living documentation, not a compliance artefact you write once and file away. Teams that revisit their top processes quarterly catch drift before it causes client-facing errors.
Fernside Studio doesn’t run automation retainers. Most engagements start with a short audit: we look at your existing SOPs (or help you write them if they don’t exist yet), tag each step by automation readiness, and scope a build around the highest-value, most feasible steps first. That’s the same workflow audit approach we use for any automation project, applied specifically to procedures you’ve already documented.
For businesses without a website that supports this kind of operational structure yet, a Studio Site with Fernside CMS gives your team a hosted, editable base to work from before layering automation on top. If you’re earlier stage and just need a fast, professional site live this week, the Launch Sprint covers that.
Pick a single SOP your team already uses. Go through it line by line and tag each step: fully automatable, AI-assisted, or human-only. You’ll likely find at least two or three steps ready to automate immediately, no new tooling required, just clearer documentation.
If you want a second pair of eyes on the audit, or you’re ready to convert tagged steps into a working system, talk to Fernside about scoping the build.