Support context
Support is faster when the report includes purchase context, SophMate version, WordPress version, WooCommerce version, PHP version, affected screen, exact timestamp, and reproduction steps. Keep the report specific enough for another operator to retry.
Redaction rules
Never send provider keys, raw server credentials, payment data, full customer records, or private logs that have not been reviewed. Use diagnostics and support to prepare safe evidence and privacy data retention to decide what should be omitted.
Request path
Use the contact page for pre-sale or website questions and the CodeCanyon support flow for purchase-related plugin issues. The support details tutorial explains what to gather before opening a request.
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 evidence is incomplete, private data may be exposed, production impact continues, or routing between host, provider, and plugin support is unclear.
Production checklist
- Gather purchase context, SophMate version, environment details, exact screen, timestamp, reproduction steps, diagnostics, and redacted evidence.
- Use CodeCanyon support for purchase-related plugin issues and the contact page for pre-sale or website questions.
- 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
- The support request is specific enough for another operator to retry.
- Sensitive data has been removed before the report is submitted.
- 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
- 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
- Verify details with the support details tutorial.
- Use Privacy and Data Retention before sharing evidence.
- 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.