SOP update brief for process approval

Use this workflow when an existing standard operating procedure no longer matches the work staff do. You will produce an update brief that shows each proposed edit, the evidence for it, the decision needed and the person who must approve it.

This is for operations leads who own process documents but need input from frontline staff, system owners and managers. Do not ask the model to rewrite the SOP before you have agreed what should change.

1. Assemble the review pack

Create one folder or workspace for the review. Give every item a date and source. Your minimum pack is:

• The current SOP, including its title, owner, version or revision date, and any linked forms or checklists.
• A feedback log containing staff comments. Keep the original wording, submitter role, date and the SOP step it relates to.
• A change register for process changes already made or planned. Include system changes, supplier changes, control changes, team hand-offs and removed steps.
• Any supporting records that settle a factual dispute, such as a current form, screen capture, meeting decision or process map.
• An approval list: document owner, operational approver, system owner where relevant, and final publisher.

Put feedback and changes into a simple table before sharing them. Use these columns: reference, source, date, SOP section, issue or change, evidence, suggested action.

Remove personal information that is not needed to decide the edit. Do not include customer records, employee case details or access credentials in the material you provide.

2. Define what the brief must decide

Write a short review instruction at the top of the pack. Set the scope before you ask for analysis. For example:

Review SOP-OPS-014 against feedback logged from 1 May to 31 July and changes CR-22 to CR-29. Identify only edits needed for the current process. Do not redesign roles, controls or service levels unless the source material explicitly requires it.

Then state the decision categories:

• Approve: the proposed edit is evidenced and can be added to the next draft.
• Investigate: the issue may be valid, but evidence is incomplete or conflicting.
• Reject: the proposed edit is outside scope, duplicates an existing instruction or is not supported.
• Escalate: an accountable owner must decide because the change affects a control, ownership boundary or linked process.

Name the approver for each category where this differs. A system owner might approve wording about a tool, while the operations lead approves the overall procedure.

3. Ask for a structured comparison

Provide the SOP, feedback log and change register together. If the files are long, work section by section, preserving the heading and step numbers from the SOP. Capability and file-handling details can differ by version, so check the xAI documentation overview before choosing how to provide the material.

Use an instruction that requires evidence and preserves uncertainty:

Compare the current SOP with the feedback log and change register.

Create an SOP update brief. For every proposed change, give:
- a unique change ID
- current SOP section and exact current wording, or “missing instruction”
- proposed replacement wording or a precise deletion
- feedback and change-register references supporting it
- operational reason for the change
- risk if the change is not made
- decision: approve, investigate, reject or escalate
- required approver
- open question, if any

Do not invent policy, system behaviour, owners, dates or evidence. If sources conflict, retain both positions and mark the item investigate. Separate editorial changes from changes to process, control, role or system use.

End with: items ready for approval, items needing evidence, and documents or teams affected by approved changes.

Ask for a table, not a narrative summary. A useful layout is:

Change ID	SOP section	Proposed edit	Evidence	Decision and approver
CH-01	3.2 Receive request	Replace the obsolete queue name	FB-04, CR-24	Approve, system owner

Keep the original SOP unchanged at this stage. The brief is a proposal record, not the controlled document.

4. Check the proposed edits against the source

Review every row marked approve or escalate. Start with high-impact sections: prerequisites, hand-offs, approvals, exceptions, records to retain and system actions.

For each row, perform these checks:

1. Open the cited SOP section and confirm the current wording is quoted accurately.
2. Open every feedback or change reference. Confirm it supports the proposed wording, not merely the general topic.
3. Check whether the edit changes a role, control, decision point, deadline or system record.
4. Look for linked documents, forms and templates named in the SOP. Record any that would become inconsistent.
5. Confirm the required approver has authority over the proposed change.

5. Spot output that is wrong

Do not judge the brief by how fluent it reads. Look for unsupported certainty and changes that quietly expand the scope.

If you see this	Treat it as	What to do
A new policy rule with no source reference	An invention or scope change	Mark it investigate and ask the accountable owner for evidence
A quoted SOP step that you cannot find	A citation failure	Correct the section reference and rerun that item only
“All staff” or “the manager” where the SOP names roles	Lost precision	Restore the exact role names and hand-off points
Two sources giving different instructions	An unresolved conflict	Keep both references and assign an escalation owner
A proposed wording change that alters a control	A material process change	Separate it from editorial edits and require the right approval

Also check omissions. Compare every feedback-log row and change-register row against the brief. Each source item must have a change ID or an explicit reason for rejection. Missing items are often more damaging than poor wording because nobody knows they were considered.

6. Run the approval meeting and hand over

Send the brief before the meeting with the current SOP and the evidence references. Ask approvers to comment against the Change ID, not in general terms. Record one of four outcomes for every row: approved, rejected, deferred or sent back for evidence.

After the meeting, add these fields to the final brief:

• decision date
• decision maker
• decision recorded in
• draft owner
• publication owner
• target review date

Hand over a single approval pack containing the signed-off brief, the decision log and a list of affected documents. The draft owner can then update only approved rows. Keep deferred and rejected items in the log so they do not return later as unexplained feedback.

When the workflow does not work

If the comparison produces too many vague changes, reduce the scope to one SOP section or one change register entry at a time. If sources conflict, do not force a combined answer. Create an escalation row and ask the named owner to decide the operating rule.

If reviewers reject the brief because it is too long, group only genuinely identical editorial corrections. Keep process, control and ownership changes as separate rows. If the source material is incomplete, publish no update brief as final. Issue a short evidence request, assign an owner and set the review back to investigate.