Training scope
SophMate rollout should include operators, not only administrators. Editors, support agents, store managers, marketers, developers, and agency users need different examples, refusal rules, approval boundaries, and escalation paths before they rely on AI output.
SOP design
Create short procedures for read-only Copilot questions, support drafts, product copy, Theme Assistant reviews, workflow approvals, and incident escalation. Pair this with First-Run Checklist, Roles and Permissions, and Approval Controls so training matches the access model.
First-week review
Review the first week of prompts, rejected plans, support drafts, approvals, and audit records. Update SOPs when operators ask unsafe questions, skip context, misunderstand approval rules, or escalate too late.
Owner and cadence
- Primary owner: site administrator or agency implementation lead.
- Review cadence: during initial setup, after hosting changes, and before adding new SophMate users.
- Escalate when operators repeatedly skip context, misunderstand approvals, use unsafe prompts, or cannot identify the right support path.
Production checklist
- Create role-specific SOPs for Copilot, support drafts, product copy, Theme Assistant review, approvals, and incident escalation.
- Review first-week prompts, rejected plans, approvals, support drafts, and audit records for training gaps.
- Record the setup owner, production site URL, staging site URL, SophMate version, WordPress version, PHP version, and active theme before rollout.
- Confirm the team can reach diagnostics and support and knows where to pause high-risk activity.
Acceptance checks
- Operators can identify when to ask, approve, reject, escalate, or stop work.
- SOPs are updated when users repeatedly miss context, risk, role limits, or support paths.
- A trusted administrator can repeat the setup path without relying on private notes or one person's memory.
- The team has a documented rollback or support path before any write-capable workflow is enabled.
Common mistakes
- Giving users access before they understand approval boundaries, refusal rules, role limits, and escalation paths.
- Inviting the wider team before provider, diagnostics, permissions, and rollback ownership have been verified.
- Treating a successful admin page load as proof that hosting, outbound HTTPS, backups, and support routing are ready.
Related operations
- Start with First-Run Checklist.
- Match procedures to Roles and Permissions.
- Use First-Run Checklist before inviting non-administrator users.
- Use Copilot Prompting and Context before team members rely on chat output.
- Use Environment and Hosting Checklist when provider or fetch tests depend on host behavior.
- Use Staging Test Data and Demo Hygiene before testing with production-like records.
- Use Operator Training and SOP Rollout before broad team adoption.