Document a process from real work
To document a process accurately, begin with the person doing the work and a recent example. Ask them to walk through the actual steps, including checks they perform from memory and messages sent outside the main system. Capture the current process before designing the improved version. Keep the observations specific: where the input arrives, what someone looks up, how they make a decision and where they record the outcome. Include at least one incomplete or unusual case. A procedure built only from the ideal path leaves the implementation team guessing when ordinary work departs from that path.
Define the boundary and responsible roles
Give the procedure a clear name, trigger, end condition and owner. For a lead-assignment process, the trigger might be a valid website enquiry and completion might mean that an appropriate team member has an assigned record to review. That boundary does not include qualifying the prospect or making an offer unless those actions are deliberately added. Name roles rather than relying solely on individual names, and identify who covers an absence. State where the procedure is stored, who can approve changes and when it was last reviewed. These details make the document usable after the original author steps away.
| SOP field | What to record |
|---|---|
| Process and owner | Name the workflow, accountable role and backup. |
| Trigger and completion | State when work begins and what counts as done. |
| Inputs and access | List required fields, source systems and permissions. |
| Steps and decisions | Name the actor, action, condition and resulting output. |
| Exceptions and review | Define the manual route, reviewer and approval boundary. |
| Version and maintenance | Record the approval date, document location and change owner. |
Describe inputs and outputs precisely
List the information required at the starting point, its source and how it should be checked. Distinguish required fields from helpful context. For an enquiry, the contact route and requested service may be essential, while a longer project description may be optional. Explain what to do when a required value is missing rather than asking an automation to guess. Define the output just as carefully: the record to create or update, the fields it contains, the person responsible and the status that indicates completion. Include an example using fictional information without exposing real customer details.
Write steps that reveal the decisions
Use direct instructions that name the actor, action and expected result. Replace a vague step such as process the enquiry with separate steps for validating information, checking for an existing record and assigning ownership. Where the route changes, state the condition and resulting action. For example, if the selected service has a named owner, assign that role; if the service is unknown, send the record to the intake queue for review. Record the source of any assignment table. An AI-assisted classification step also needs an agreed list of categories and a route for uncertain or conflicting information.
Use a concise example to test the SOP
Consider this illustrative lead-assignment procedure. Trigger: a new enquiry passes the form's required-field checks. Step one: look for an existing contact using the approved matching rule. Step two: create or update the enquiry record without overwriting unrelated notes. Step three: match the selected service to the assignment table. Step four: assign the owner and record the submission source. Step five: notify the owner once. Exception: missing ownership or a possible duplicate goes to the intake queue. Completion: the assigned record is visible to its owner. This example leaves outreach with staff; automated customer messages would need their own instructions and approval boundaries.
Document a process with clear exception paths
Add a short exception section for missing information, unavailable systems, conflicting records and repeated events. Define how the team can tell whether an action succeeded before trying it again, particularly when repetition could create another record or send another message. Name the person who investigates failures and the manual route they can use. Specify what the automation may read, update, create or send, using only the access needed for its scope. Keep credentials out of the SOP itself. Where review is required, explain what the reviewer checks and what approval permits the workflow to do next.
Have someone else run the procedure
Give the draft and representative examples to a colleague who did not write it. Ask them to complete the work using the document and record every point where they need extra explanation. Revise the procedure, then compare its completed outputs with the agreed standard. Use these examples as acceptance cases for the automation, including the exception paths. After launch, update the SOP when ownership, systems or rules change and record why the change was made. GenRev's SOP optimization work can turn this documentation into a practical handover for the people operating and maintaining the process.
When you document a process, include the point at which automation must stop and a person must decide. That boundary gives both the builder and the process owner a clear review rule.