AI Support Readiness Score: How to Grade Launch Risk

Most demos over-score readiness because they ask polished questions against the cleanest help-center content. Customers do not behave that way. They ask with missing context, old product names, policy exceptions, billing edge cases, security concerns, and emotional language.

A readiness score should start from the sources and workflows that will actually constrain the AI. If the answer is not written down, if two sources disagree, or if the handoff rule is informal, the score should stay low even when the model sounds fluent.

The Meihaku score uses six operational dimensions because AI support failures rarely come from one weak prompt. They usually come from several weak controls at once: stale knowledge, conflicting policy, shallow tests, vague escalation, no source owner, and no post-launch wrong-answer review.

Each dimension should be scored from evidence. A support leader should be able to point to the article, macro, SOP, ticket sample, test run, reviewer decision, or metric that justifies the score.

A customer intent is ready when the team can prove four things: the question is in scope, the source is current, the answer includes the conditions that matter, and the AI knows when to stop. If any of those are missing, the intent should be restricted, blocked, or human-owned.

This is stricter than generic chatbot testing, but it matches the risk of customer-facing support. A refund answer, account access answer, security answer, or regulated complaint does not become safe because it is well written.

A low score does not mean the AI project should stop. It means the launch boundary should shrink. Start with the intents that have current source evidence, clear conditions, and low exception risk, then use the blocked-intent list as the knowledge cleanup backlog.

A high score does not mean every support question should be automated. It means the team has enough evidence to expand in the approved zones while keeping restricted and human-only topics out of the AI's final answer path.

The output should be a working launch map, not a slide. Every score review should create a list of approved intents, restricted intents, blocked intents, source fixes, and human-only topics. That map can then guide vendor configuration, test sets, QA sampling, and post-launch monitoring.

When the score changes, the source evidence should change too. A score increase without updated articles, resolved conflicts, tested edge cases, or clearer handoff rules is usually optimism, not readiness.