Playbooks and Slash Commands

What Playbooks and Slash Commands does

Use built-in and custom playbooks for analytics, operations, marketing, support, and action plans, then run them from Copilot slash commands or the playbook gallery.

SophMate is built for WordPress and WooCommerce teams that want useful AI help without turning the site into an invisible automation box. The module keeps the work close to wp-admin, where products, orders, pages, policies, users, and operational history can be reviewed by the people responsible for the site.

Best-fit teams

• Teams with repeatable requests such as weekly summaries, coupon briefs, product copy, support drafts, and operational checklists.
• Agencies that want to standardize useful prompts across client sites while preserving local approval rules and context.
• Teams that want WordPress-native context, permission checks, and audit history instead of a disconnected AI workspace.
• Buyers evaluating whether the module can fit a real operating process, not only produce an impressive demo response.

What teams see in wp-admin

Playbooks surface inside Copilot as repeatable slash commands and as reusable workflow definitions. They are strongest when the team has a recurring report, support response, campaign brief, or action-plan pattern that should not depend on whoever writes the prompt that day.

Best-fit jobs

• Run /weekly-summary for a sales overview.
• Run /coupon-builder to draft a WooCommerce coupon change plan.
• Export proven playbooks and reuse them across client sites.

Product capabilities

• 39 built-in playbooks
• Analytics, action, chat, and watcher types
• Parameter prompts
• Import and export
• Custom templates for agencies

Setup prerequisites

• Review built-in playbooks, disable anything outside the site operating model, and document the required parameters for shared commands.
• Prepare example inputs for analytics, campaign, support, and action-plan playbooks so users learn the expected shape.
• Set provider budgets and role access before giving users a workflow that can become a site-changing plan.
• Keep staging, backup, or rollback expectations clear whenever the feature can affect public content, commerce data, customer messages, or theme output.

Operating notes

Start with a low-risk example, check the visible output, and promote the pattern only after the team can explain the inputs, review point, owner, and rollback path.

Rollout checklist

• Publish a small command set, review real outputs, then expand only the playbooks that users can complete without guesswork.
• Version agency or client-specific templates so changes to instructions can be reviewed before reuse.
• Name the owner of the first rollout window and schedule a review before making the feature a default team habit.
• Capture what changed during the first run so future administrators can distinguish setup mistakes from product behavior.

Risks and guardrails

• Risk: vague shared prompts create inconsistent outputs. Guardrail: require purpose, parameters, expected format, and approval behavior for each playbook.
• Risk: imported templates may not fit a client site. Guardrail: review local roles, WooCommerce rules, and source context before reuse.
• Treat convenience as a rollout risk whenever the feature can write data, contact customers, publish content, or change the storefront.
• Keep permissions, budgets, audit review, and rollback expectations visible during the first production use.

When to use a different path

Do not turn a vague prompt into a shared playbook. A useful playbook has a clear purpose, required parameters, expected output, and known approval behavior.

How it stays governed

The important pattern is draft, review, approve, then execute. Read-only questions can stay conversational. Work that affects products, coupons, content, customers, workflows, images, or settings should move through a reviewed plan, workflow run, or publishing step. That is why Playbooks and Slash Commands belongs beside approval-based action plans, audit and diagnostics controls, and the broader SophMate tutorial library.

Evidence to capture

• Keep template version, parameters, generated output, reviewer edits, and the action-plan or workflow handoff that followed.
• Track which commands users abandon because required inputs or output format are unclear.
• Link evidence to the relevant docs, tutorials, or use case when the feature becomes part of a repeatable operating procedure.
• Keep evidence concise enough for support and governance review; avoid exporting secrets or unnecessary customer data.

What to measure after rollout

Track repeat usage, parameter completion, reviewer edits, and stale templates. A playbook that saves time but produces unclear output needs better instructions before wider rollout.

Decision record

• Record the approved command library, template owners, version review cadence, and import policy for agency templates.
• Write down the first production scenario, the reviewer, and the evidence that would prove the rollout is working.
• Revisit the decision after the first incident, failed run, support ticket, or policy change rather than letting the original setup become permanent by accident.

Where to go next

Compare this module against the rest of the SophMate feature library, map it to a team scenario in use cases, or start with a practical guide from SophMate tutorials.