Support SLA and Escalation Matrix

Severity model

Support requests should be triaged by production impact, customer visibility, revenue risk, privacy exposure, data correctness, and whether automation can be paused. A cosmetic admin issue should not follow the same path as a checkout-impacting workflow or privacy-sensitive support incident.

Escalation matrix

Map each severity level to the owner who can pause workflows, contact hosting, contact the provider, open CodeCanyon support, update customers, or approve rollback. Pair this with Contacting Support, Error Reports and Support Codes, and Incident Response Runbook.

Communication standard

Customer or client updates should explain impact, current workaround, owner, next update timing, and what evidence is safe to share. Do not include provider keys, raw logs, purchase codes, payment data, or unrelated customer records.

Owner and cadence

• Primary owner: support lead or site administrator responsible for triage and evidence handling.
• Review cadence: when an issue is reported, before support contact, and after recovery to improve the runbook.
• Escalate when severity, response owner, customer communication, or routing between host, provider, and plugin support is unclear.

Production checklist

• Define severity levels by production impact, customer visibility, revenue risk, privacy exposure, data correctness, and automation state.
• Map each level to hosting owner, provider owner, CodeCanyon support owner, rollback owner, and customer communication owner.
• Capture exact timestamp, affected user, affected screen, SophMate version, WordPress version, PHP version, and reproduction steps.
• Redact provider keys, credentials, payment data, private customer details, and raw logs before support handoff.

Acceptance checks

• Support requests can be triaged without guessing who owns the next response.
• Customer-facing updates include impact, workaround, owner, next update timing, and safe evidence only.
• The support report lets another operator reproduce or triage the issue without receiving secrets.
• The team knows whether to escalate to hosting, provider support, CodeCanyon support, or internal operations.

Common mistakes

• Treating every support request the same instead of separating cosmetic, operational, revenue, privacy, and customer-visible severity.
• Retrying or changing settings repeatedly before preserving the exact error report, timestamp, and affected screen.
• Opening support requests with raw logs or vague descriptions instead of redacted diagnostics and reproduction steps.

Related operations

• Prepare evidence with Contacting Support.
• Use Incident Response Runbook when severity is production-impacting.
• Use Incident Response Runbook when production behavior is affected.
• Use Contacting Support before opening a support request.
• Use Support SLA and Escalation Matrix before customer-visible support routing.
• Use Error Reports and Support Codes before redacting or sharing an error report.
• Use Migration and Reindex Review before restarting workflows after updates.
• Use Post-Incident Review and Prevention before returning paused work to normal scope.
• Use Changelog and Release Note Review before release decisions.