Find the failed step before suggesting a fix
When a reader has paid for your skill but cannot use it, check four things separately: the purchase, the account they are signed into, the access attached to that account, and the connection inside their AI app. Start with the exact place where they get stuck. Do not ask them to buy again while the original payment is unresolved.
A receipt is evidence about a transaction. A successful login is evidence about an account. Neither alone proves that the purchased method is available in the reader’s current AI conversation.
The decision tree below is a proposed author support procedure. The worked case is fictional; no customer account, payment, or sandbox access was changed or tested for this article. Adapt the procedure to your platform’s documented controls and support responsibilities.
Acknowledge the purchase without guessing the cause
Begin with a short response that recognizes the reader’s experience and asks for information you can actually use:
Thanks for letting me know. I’ll help trace where access is stopping. Please don’t purchase again while we check the original order. Which step fails: opening your access page, signing in, finding the skill, connecting it to your AI app, or starting a task? Please send the error wording and your order reference through this support channel.
Ask for the purchase email through a private support route when you need it to locate the order. Do not request passwords, full card numbers, one-time sign-in codes, or access tokens. A screenshot may help, but tell the reader to hide unrelated conversations and account information.
In a public subscription discussion, u/Sorry_Sentence3229 described having a receipt while lacking the expected access:
“my account is still stuck on the Free plan with zero Pro access.”
This was a personal report about Claude, not an independently diagnosed incident or evidence of a general defect. It illustrates why “your payment succeeded” is not a complete answer to a reader asking to use what they bought. Original paid-access report.
Keep your first reply free of theories such as a delayed payment, wrong account, or platform outage until you have evidence. You can be helpful before knowing the cause.
Use this support decision tree
Work from the reader’s last successful step. The branches are questions to investigate, not instructions to override access checks.
| Check | If the answer is yes | If the answer is no or unclear |
|---|---|---|
| Can you locate the original order? | Confirm its product and current payment state. | Ask for the order reference and purchase email privately; escalate unmatched records. |
| Does the order show the expected completed purchase? | Check which account should receive access. | Resolve the transaction status through the platform or payment support process. |
| Is the reader signed into that account? | Inspect the product access shown for it. | Use the platform’s verified recovery process; do not casually transfer access. |
| Does the account show access to this skill? | Check the AI app and connection. | Escalate the mismatch with order and account evidence. |
| Can the app connect and recognize the purchased skill? | Start a small task. | Check supported client, account requirements, permissions, and the exact connection error. |
| Can the reader complete the first meaningful step? | Confirm what now works and close or narrow the issue. | Distinguish access trouble from a method or response-quality problem. |
A “no” at one row does not automatically explain every later symptom. Record what you know and stop making changes when the next step depends on a platform administrator or payment provider.
Check payment without asking the reader to pay twice
Locate the order in the system that sold the skill. Check the product, purchase time, and current transaction state. A pending authorization, completed payment, refund, and canceled subscription are different situations. Use your provider’s definitions rather than interpreting a bank screenshot on its own.
If the platform record and the reader’s receipt disagree, preserve the references and escalate. Do not promise that a charge will disappear or that access will return at a particular time unless the responsible provider has confirmed it.
Also verify the offer itself. A reader may have bought a book, a course bundle, a gift, or a future release whose access differs from the skill they are trying to open. Explain any discrepancy respectfully and show the relevant purchase terms. Do not silently substitute a different product to make the ticket disappear.
Your working note can be brief: order located; expected product confirmed; payment status verified; access still missing. That prevents the next person handling the request from making the reader repeat the entire story.
Check identity without treating the reader as the problem
People use personal and work email addresses, different login methods, and several devices. A mismatch is a possibility to investigate, not a conclusion to announce.
In a March 2024 course-access question, u/IMEVIIL wrote:
“I created an account with the wrong email (added an additional 0 to the email address)”
The user also said a course had been purchased on that account. This is an individual example of an identity problem, not evidence that every missing purchase is user error. Original Udemy account question.
Thinkific’s own support documentation recommends checking the student account and email spelling when a password-reset message does not arrive. Its mobile troubleshooting guide also describes cases where a different sign-in method creates a separate account. These are examples from Thinkific, not claims about identical behavior in Skillfully. Thinkific password-reset guidance and mobile sign-in troubleshooting.
Ask the reader to check the account displayed in the service that owns the purchase. If they need to recover or correct it, follow that service’s verification procedure. Never move a purchase merely because someone can name an email address or provide a screenshot. Avoid revealing another account’s details while trying to help.
Check the access record separately from the login
An account can exist without owning a product. Thinkific explicitly describes students who create accounts without enrolling in learning products, including some gift or group-order situations. That distinction is useful when designing any paid-content support process. Thinkific’s student account and enrollment explanation.
For your skill, look for the platform’s authoritative indication that this account may use this product. If you cannot see it, ask the platform support team to check; do not infer access from the presence of a name in a customer list.
Where your authorized support tools permit a correction, document what changed and why. Use the narrowest supported repair. A public link or unrestricted copy may appear to resolve the immediate complaint while changing the offer’s access rules and creating a different problem.
If a correction is pending, give the reader a realistic next update you can own: “I’ve sent the order and account mismatch to platform support. I’ll update you tomorrow even if it is still under investigation.” That is a communication commitment, not a promised resolution time.
Check the client only after the account has access
Once the purchased skill is available to the correct account, investigate the AI app. Record its name, the relevant interface, and the exact error. Confirm that the reader is following the route you support, not an older guide for a different client.
Separate “I cannot connect” from “the assistant does not seem to use the method.” The first points toward account, permission, or connection checks. The second may require a specific task and an examination of the response.
If the platform instructs the reader to reconnect, explain which connection and what state should appear afterward. Avoid a list of unrelated resets. Changing several things at once makes it harder to know what resolved the problem and can interrupt other working tools.
A managed workplace account may require administrator approval. Send the reader to that process rather than suggesting a workaround around their organization’s controls.
Worked example: trace one fictional access complaint
Imagine an author, Omar, who sells a skill for planning a local history interview. A reader says, “I paid yesterday, but the assistant tells me it cannot find the skill.” This example illustrates the support reasoning; it is not a report from a real buyer.
Omar first asks where the reader sees that message and locates the purchase. In the fictional case, the order is completed and names the expected interview-planning skill. That closes the payment question for now; it does not close the ticket.
Next, the reader checks the account shown on the access page. It differs from the account attached to the purchase. Omar directs them through the platform’s ordinary sign-in process for the purchasing account. He does not transfer the order or request their password.
After signing in, the reader can see the skill on the access page. The AI app still cannot find it. This new observation narrows the remaining problem to the app’s connection or use of the service. Omar now follows the supported connection instructions for that app, with the reader controlling authentication.
The final check is a small task: prepare five interview questions about a neighborhood shop, beginning by asking what period the interview should cover. If the reader reaches that first question, Omar records that specific result. He does not claim the entire interviewing method has been validated.
The useful support record is a sequence of observations: purchase confirmed, account mismatch corrected through normal sign-in, access visible, connection checked, first task attempted. Your real ticket may stop at any of those stages.
Close on a result the reader can recognize
Ask whether the reader can now start the intended task. Record unresolved limitations rather than labeling every ticket solved once a login succeeds. If access works but the method gives poor guidance, move that concern into a quality review with an example the reader is comfortable sharing.
Use measuring agent skill quality to define the difference between reaching the skill and getting useful work from it. Then improve your welcome instructions if several tickets stop at the same step.
If you are designing the reader journey for a book-based skill, visit Skillfully and choose Book onboarding. Bring the first task, your promised access route, and the point where a new reader might need help.