Lesson 1 covered onboarding as part of productizing your plugin. This lesson goes further into what happens after launch, when real customers are running your product against real WordPress sites and real AI providers, and something inevitably goes wrong. A typical plugin bug is usually reproducible: same input, same broken output, every time. An AI feature isn’t like that. The same prompt against the same model can produce a different answer on two separate calls, a provider can degrade or rate-limit without warning, and “it’s not working” from a customer can mean five different things depending on where in the pipeline the failure actually happened.
This lesson assumes you’ve already built the audit-logging pattern from Course 4’s
building-your-own-audit-log lesson, or an equivalent, into your product. If you
haven’t, that’s the single highest-leverage thing to add before launch, this lesson
explains why.
Step 1: Documentation an AI product actually needs
Beyond the onboarding documentation Lesson 1 covered, an AI product needs a specific troubleshooting reference that maps symptoms to causes, because the same visible symptom (“nothing happened” or “got a strange answer”) can come from several different places in the pipeline.
| Customer-visible symptom | Likely real cause |
|---|---|
| ”The AI feature did nothing” | A permission_callback rejection, an unauthenticated request, or a rate limit, not necessarily a bug |
| ”It gave a weird or wrong answer” | The model itself, not the plugin, a prompt or retrieval quality issue (Course 6’s RAG grounding is the fix here, not a bug report) |
| “It worked yesterday, not today” | A provider-side outage, model deprecation, or a quota reset, worth checking the provider’s own status page before assuming a regression |
| ”It’s slower than before” | Provider-side latency, or increased content volume feeding a RAG pipeline, both external to your code |
Publishing this mapping, in plain language, as part of your documentation does two things: it lets a meaningful share of customers self-diagnose before ever opening a ticket, and it sets the expectation up front that not every strange result is a plugin defect.
Step 2: Pick a support channel that matches your actual team size
Whatever you choose, state a realistic response-time expectation publicly and keep it. A stated 48-hour response window you consistently meet builds far more trust than an implied “always available” promise you can’t.
Step 3: AI-specific failures need AI-specific expectations
Set these expectations in your documentation and, ideally, directly in your product’s error messaging, not just buried in a support macro you paste in reactively:
Step 4: Use your own audit log to diagnose what a customer reports
This is where the audit-logging habit Course 4 built, and that a later course in this
track returns to for deeper observability, pays off directly in support. When a
customer reports “the AI feature did something wrong,” you almost never have enough
information from their description alone: you don’t know which ability ran, what
arguments it received, whether permission_callback passed, or what the provider
actually returned. An audit log answers all of that, if you ask the customer for the
right thing instead of guessing.
A screenshot shows what the customer saw. It doesn’t show what ability ran, what arguments were passed, or what the model returned. If your audit logging from Course 4 is in place, asking the customer for the approximate time of the issue and, ideally, an export of their own audit log entries around that time turns a vague “it didn’t work” into a specific, diagnosable event.
// A simple query pattern against the audit log table from Course 4,
// filtered to a time window a customer reports
global $wpdb;
$table = $wpdb->prefix . 'mcp_audit_log';
$rows = $wpdb->get_results( $wpdb->prepare(
"SELECT * FROM {$table} WHERE created_at BETWEEN %s AND %s ORDER BY created_at ASC",
'2026-07-20 14:00:00',
'2026-07-20 14:15:00'
) );Test it
Simulate a support scenario before you actually need to run one. Trigger a permission rejection and a rate-limit block deliberately in a test environment, then confirm your own audit log captures enough detail (ability name, permission result, timestamp) to diagnose each without needing anything else from the customer.
Recap
An AI product fails in less predictable ways than a typical plugin, and documentation, support channel choice, and expectation-setting all need to account for that specifically, not just repeat generic plugin support advice. The single highest-value habit is one this track already built: a real audit log from Course 4, asked for by timestamp rather than guessed at from a screenshot, turns a vague customer complaint into a diagnosable event and is usually faster than any other troubleshooting step available to you.
Resources & further reading
- MCP Security & Authentication for WordPress, this track, the audit-logging lesson referenced above
- Plugin Developer FAQ, developer.wordpress.org