Ask three employees how your business handles a rush request. You may get three answers.
One person checks the schedule and adds a fee. Another calls the owner. The third accepts the job, then hopes the crew can fit it in. Your written procedure might say, “Handle rush requests based on availability.”
A person can work around that sentence. Software cannot. It needs to know who decides, which schedule counts, and what “available” means.
That gap causes many automation projects to fail. The tool exposes a process that already depended on memory and judgment.
Follow one real case
Choose a process that your team completes at least ten times a week. Follow one item from start to finish.
For a service request, capture:
- where the request arrives
- which facts the first employee collects
- who owns the next action
- which decisions require approval
- where the team records the outcome
Use screenshots, sample emails, and actual form fields. A flowchart that says “process request” hides the useful details.
Mark every point where someone says, “It depends.” Ask what it depends on. The answer may involve job value, service area, customer history, crew skill, or safety risk. Write the condition down.
Count exceptions for one week
An SOP often describes the clean path and ignores the work that takes time. Keep an exception log for five business days.
| Item | Expected path | What happened | Who resolved it |
|---|---|---|---|
| New estimate | Form to estimator | Address outside service area | Office manager |
| Supplier invoice | Email to accounting | PO number missing | Project lead |
| Appointment | Reminder sent | Customer requested text only | Dispatcher |
Ten examples will tell you more than a two-hour meeting. You will see which exceptions need a rule and which need judgment.
Do not force rare judgment calls into a brittle rule. Route them to a named person with the source information attached.
Give each decision an owner
“Management approval” is not an owner. Name the role that can approve the item and the backup when that person is unavailable.
A useful procedure says:
The dispatcher may schedule emergency work inside the current service area when an emergency slot is open. The service manager reviews requests outside the area or after the emergency slots fill.
The rule defines authority and the handoff. An automation can check the area, read the schedule, and route the exception without pretending to make the manager’s decision.
Run the readiness test
Score the process before you choose a tool.
| Question | Ready | Needs work |
|---|---|---|
| Do all requests enter through a known set of channels? | Most inputs reach one queue | Employees hunt across inboxes |
| Does each required field have a definition? | The team agrees on each field | “Urgent” means something different to each person |
| Does every decision have an owner? | One role owns each branch | The owner settles disputes from memory |
| Can the team spot a wrong result? | A person can check the source | Nobody can explain why the result changed |
| Can the team work during an outage? | A manual path exists | The process stops with the tool |
Four ready answers support a small pilot. Two or fewer mean the business should clean up the process first.
Fix the source before the prompt
Teams often try to solve unclear policy with a longer AI prompt. The prompt becomes a second SOP, then drifts away from the first one.
Keep approved rules in one place. The automation should read those rules or use a controlled copy with an owner and review date. Update the policy before you update the prompt.
If your rate card changes, change the rate card. If your service area expands, change the service-area record. Do not bury business facts inside instructions that only a developer knows how to find.
Automate one clean slice
Choose the part with stable inputs and a cheap correction path. The system might validate a form, create a task, or draft a confirmation. Keep pricing exceptions and safety decisions with people.
Run the first slice beside the manual process for two weeks. Compare results. Record every correction and change the source rule when the same correction appears twice.
Good automation starts with an honest procedure. The writing does not need polish. It needs enough detail for a capable employee to handle a normal case and know where to send an exception.
If your process lives in the owner’s head, book a free Opportunity Scan. We can map the real work before you pay to automate it.