Playbook, online course

A learner who paid and cannot get in, handled in one step

Most handovers can afford a step or two of triage. This one cannot. Somebody who has paid for a course and cannot open it is losing the thing they bought while they wait, and every additional question the assistant asks is time they spend locked out.

Why this is not the general answer

The handling pattern for asking for a person holds across every trade. What follows is the part that does not.

  • The person has already paid, so the relationship is a customer with an outage rather than a prospect with a question.
  • The problem is nearly always identity, and identity is the one thing a chat window is structurally unable to establish.
  • The urgency is real and time bound if the course is a live cohort with sessions running.
  • Collecting the right two details up front removes an entire round trip, which is the whole value the assistant adds here.

How it arrives

  • i paid and i cannot access the course
  • i need someone to sort my account out
  • can someone call me about my access
  • my cohort starts tomorrow and i cannot get in
  • i have emailed support and had no reply
  • who do i talk to about my purchase

What has to be indexed for this to work

Material behind this answer
Support hours and the realistic reply timePublished honestly. A learner told when to expect a reply will wait; one told shortly will chase, and chasing is what fills the inbox.
What support needs to identify a purchaseThe purchase email and the approximate date. Naming these means the assistant can collect them rather than support having to ask.
Any urgent route for live cohortsIf a cohort is running, there is usually a faster channel. Publish it, because this is the case where a next working day reply is not good enough.

The reply

A reply worth copying
That needs somebody who can see the account, so I will pass it straight on rather than take you through steps. If you give me your name and the email address you bought with, support can find the purchase immediately. If your cohort has already started, say so in the message and it will be prioritised.

It skips triage entirely, which is correct when the person has already paid, and it collects exactly the two details that let support act without replying to ask. Inviting the cohort detail is what gets the urgent ones seen first.

Where it stops

The trigger. Anybody stating they have purchased and cannot access. No diagnostic steps first, no confirmation that they really did buy it.

The handover, worded
I will pass this to support now. Give me your name and the email you bought with, and add anything about which course and when it starts, and they will come back to you.

It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.

Never say this here

Out of bounds

  • That there is no record of a purchase, since the assistant cannot look.
  • A reply time the business does not publish.
  • Ask for a password, a code, or card details.
  • Suggest buying again to resolve the problem.

Questions

Should it try any troubleshooting first?
Only the three common causes if the learner has not mentioned paying. Once payment is mentioned, go straight to a person. The cost of a wasted round trip here is much higher than the cost of a handover that might have been avoidable.
What if we cannot reply quickly?
Then publish the real timescale and have the assistant state it. A learner who knows they will hear tomorrow morning is unhappy but calm. One who was told shortly and hears nothing for a day writes a review.
Is a form the right route for this?
It is the route that exists, and it works if the message reaches somebody quickly and carries the two details that let them act. If your course runs live cohorts, publish a faster channel alongside it.

Keep reading

Try it on your own material

Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.