Safe support information
What to send when you contact support, and what never to send.
Never send
- Passwords, for any account — yours, a student's, the site's, the hosting.
- Administrator accounts created for support. If access is genuinely needed, that is arranged separately and revoked afterwards.
- API keys, license keys or tokens pasted into a message thread.
- Payment details, or full order records containing them.
- Students' personal data — names, email addresses, phone numbers. Describe the account, do not identify the person.
- Database exports.
Anything sent in a support message may be stored, forwarded and read by more than one person. Send the least that answers the question.
Send this
What is happening
One sentence on the symptom, and one on what you expected instead.
A student who bought the Bread Basics course sees the no-access message. I expected the course to open after purchase.
Where
The URL of the page where it happens. A course URL and a lesson URL are both fine — they are public addresses, not secrets.
Who it happens to
Describe the account by its capabilities, not its identity:
A customer account, not an administrator. It works for administrators.
If a specific order matters, send the order number, not the customer's details.
When it started
Whether it always did this, or started after a change — an update, a settings change, a new plugin, a theme change. This narrows the search more than anything else you can send.
What you already checked
Save a round trip by listing what you have ruled out:
Order is in a completed status. The right product is attached to the course. No permission rule on the course. Tested in a private window with a real student account.
Screenshots
Useful, and easy to over-share. Before sending one, check it does not contain a student's name or email address, an order with payment details, or a browser window full of other tabs.
Crop to the part that matters.
Reproduce it first
Support cannot act on "a student says it does not work". Reproduce it yourself:
- A private window.
- A test account that is not an administrator, in the same situation as the student.
- The exact URL they used.
If you cannot reproduce it, say so — that is itself useful information, and it points at the student's account or browser rather than the site.
Check these before writing
Half of all reports resolve here:
| Check | Article |
|---|---|
| Are you testing as an administrator? | Test the course as a student |
| Is the lesson attached to a course and a section? | A lesson does not appear |
| Which of the four access gates applies? | Access precedence |
| Is the order in a paid status? | A student cannot access a paid course |
| Were the permalink rules rebuilt after a URL change? | Custom slugs |
Environment details
Helpful, and safe to send:
- WordPress version.
- POM Theme and POM LMS versions.
- Whether WooCommerce is active, and whether subscriptions are in use.
- Any caching or security plugin in front of the site.
What is not a POM LMS problem
Worth checking before you write, because these are answered elsewhere:
- Payments, refunds and subscription billing — WooCommerce and its payment gateway.
- Video playback and embedding permissions — YouTube or Vimeo.
- Emails to students — POM LMS sends none. Any email is your mailing tool's or WooCommerce's.
- Site colors, fonts and layout — POM Theme.