Skip to content
Agency Pilot

Feature

SOPs and automations

Most agency work is the same work, done again. The difference between a business and a job is whether that fact is written down anywhere.

An SOP library that is actually used

Processes live next to the clients they run on, not in a documents folder someone bookmarked in 2023.

Procedures become tasks

Applying an SOP to a client creates the real, assignable, due-dated tasks rather than a checklist nobody ticks.

Versioned, with history

Every change to a procedure is recorded, so you can see what the process was when a job was done under it.

Rules with conditions

Trigger on an event, filter it with conditions, and run a sequence of actions — including a wait before the next step.

Actions that do real things

Send an email or SMS, notify the team, create or update a task, create a lead or client, tag records, or call a webhook.

Testable before it is trusted

Dry-run a rule against a sample payload and see what it would have done, with a full execution log afterwards.

Why SOPs usually fail

Almost every agency has written its processes down at least once. The document exists. Nobody opens it, because opening it is a separate act from doing the work, and the work is what is urgent.

The fix is not better documents. It is removing the gap between the process and the task list. When applying a procedure to a client produces the actual tasks — assigned, dated, appearing in the same place all other work appears — following the process becomes the path of least resistance rather than an act of discipline.

That also makes the process improvable. If step four is always late, you can see it, because step four is a task with a due date and not a line in a Google Doc.

What automations handle

A rule has three parts: what starts it, what has to be true, and what happens. Triggers come from events in the system or from a signed webhook, so anything that can post JSON can start a rule.

Conditions are ordinary comparisons — equals, contains, greater than, is empty, starts with — combined with and/or. They exist so that a rule can be specific enough to be safe: fire on a new lead, but only when the source is paid search and the client is this one.

Actions run in sequence and can wait between steps, which is what makes follow-up sequences possible rather than just instant reactions.

  • Email and SMS, sent through your own connected providers
  • Internal notifications to the right person on your team
  • Create a task, update a task, create a lead, create a client
  • Add or remove tags to keep segments current without manual tidying
  • Call an outbound webhook, so anything you already use can be part of the chain
  • Wait a set duration before the next step

Test it before you trust it

Automations that silently do the wrong thing to a client are worse than no automations, so a rule can be dry-run against a sample payload. You see the conditions evaluate and the actions that would have fired, without anything actually being sent.

After it goes live, every execution is logged with what triggered it and what happened. When someone asks why a client got a text at 6am, the answer is available rather than deduced.

Starting from a template

You do not have to invent the first few. Rules can be created from templates and then edited, which is usually faster than designing a process from an empty screen.

The same is true of SOPs: the useful pattern is to write the one you already do badly, apply it to one client, and fix it from what the task list tells you.

What this does not do

Better to find this out here than three weeks in.

  • SMS actions need your own Twilio or GoHighLevel account connected; email actions need a connected mailbox or sending provider.
  • Rules run asynchronously. They are queued and executed rather than firing synchronously, so an action lands within moments rather than instantly.
  • This is not a visual flowchart builder with branching paths. A rule is a trigger, conditions and an ordered list of actions.

Questions

What happens if an action fails?
The execution log records the failure with the reason, so it surfaces rather than disappearing. The rest of the sequence does not silently pretend to have run.
Can a client see our SOPs?
No. Procedures are internal. Clients see tasks and projects that have been shared with them, not the process behind them.
Can I run a rule manually?
Yes — a rule can be enqueued on demand, which is useful for backfilling or for a process you want to start by hand.

Write the process down once

Start with the one you repeat most, and let it create the tasks from then on.