Direct answer
Five steps. First, read chapter 5.2 of the standard and list every requirement that maps to something your system does. Second, find where each requirement lives in your actual configuration — not where it lives in the vendor's documentation. Third, test with real customer questions, including deliberately awkward ones. Fourth, record every requirement you cannot currently satisfy, with the reason. Fifth, fix the highest-risk gaps first and retest, keeping the before-and-after evidence.
Step 1 — read the handover clauses, not the whole standard
Start at 5.2, the handover section, rather than at the beginning. This is where the operational requirements sit, and it is where a gap has the most direct effect on a customer.
Produce a plain list of requirements in your own words, each with its clause number beside it. If you cannot write a requirement in your own words, you do not yet understand it well enough to check it.
Step 2 — find where each requirement actually lives
For each item on the list, locate the configuration that implements it: a setting, a script, a rule, or a documented manual practice. Two outcomes are equally informative:
- You find it — record where it is and who owns it.
- You cannot find it — record that too. A requirement with no location is a finding, and usually the important one.
The most common result at this step is discovering that a handover setting exists on paper but is switched off, or is set to a value nobody chose.
Step 3 — test with real questions, including awkward ones
Build a test set from questions your customers genuinely ask, then add the cases the standard names: a customer who explicitly asks for a person, a question touching information security, a question about something time-critical, and a question the system will not understand no matter how it is phrased.
Run each one and record what the system does. The purpose is not to score the AI's answers — it is to observe whether the handover behaves as required.
Step 4 — record what you cannot satisfy, and why
A gap register is the deliverable of a self-check. Each row should carry the requirement, its clause, the observed behaviour, the reason for the gap, and the risk if left alone.
Be explicit about which gaps are configuration problems and which are product limitations. They have different fixes: the first you change, the second you either work around or change vendor over.
Step 5 — fix, retest and keep the evidence
Prioritise by customer risk rather than by ease. A missing handover on an information security conversation outranks a slightly slow response on a routine question.
Then retest against the same test set and keep both results. The before-and-after is what turns a self-check into something you can show — to a customer, a platform, or a reviewer asking how the requirement is met.
Key facts
| Method | Five steps: read, locate, test, record, fix and retest |
| Starting point | Chapter 5.2 (handover) rather than chapter 1 |
| Deliverable | A gap register with clause references and before-and-after test evidence |
| Common first finding | A handover setting that exists but is disabled or left at an unexamined default |
Sources
- GB/T 47746—2026, clause 5.2 (handover requirements, both directions)
- GB/T 47746—2026, clause 5.2.2.6 (scenarios to include in the test set)
Follow-up questions
How long does a self-check take?
For a small business running a single AI customer service channel, the read-and-map steps can be done in a working session; the testing step depends on how many real questions you can assemble. The work is not long — the discipline is in recording gaps honestly rather than declaring compliance.
Do I need a consultant?
No, but do not skip step 4. The failure mode of a do-it-yourself self-check is not incompetence, it is optimism — a gap that was noticed and quietly not written down. A reviewer's most useful question is simply to ask for the gap register.
What if my vendor says their product is compliant?
Ask which specific requirements their product implements and where the setting is. Compliance is a property of your configured service, not a badge on a product page — and the configuration is what the customer experiences.