Original diagram by Citera. Testing method developed for this guide. Feature reference: Google Business Agent Help. This is not a Google certification or interface screenshot.

A successful setup screen tells you that configuration was saved. To review the shopper experience, you need to ask questions and compare the answers with information the business has approved.

The method below is a suggested quality-review process, researched on November 9, 2026. It does not claim to measure all customer conversations, guarantee consistent answers, or reproduce Google’s internal evaluation. Its purpose is to produce a useful issue record that a team can act on.

The free Business Agent workbook contains twelve starter questions, editable evidence fields, review statuses, and a place to record fixes and retests. Replace the examples with questions that matter to your actual products.

Define the expected answer before testing

For every question, record an approved source URL and the fact or policy the answer should respect. If the expected answer is unresolved internally, ask the relevant product or policy owner first. An uncertain company policy cannot serve as a reliable test oracle.

Keep the expected fact specific. “Material is 100% cotton for variant X” is testable if the specification supports it. “The answer feels helpful” is too broad on its own. You can assess helpfulness separately by checking whether the response addresses the question, explains a necessary condition, or points to a useful next step.

Do not infer an integration from conversational wording. A response about an existing order is not evidence that the agent can access that shopper’s private order. Record exactly what was shown and what action was possible.

Use a small set of distinct buying questions

Start with questions that exercise different information needs. Our workbook includes twelve starters; twelve is an editorial workload choice, not a statistical requirement.

Choose at least one ambiguous question, such as “Will this work for me?”, and record whether the response requests useful clarification or makes an unsupported assumption. Use fictional customer scenarios rather than entering real order numbers, addresses, or other private information into a public test.

For a question with meaningful answer variation, repeat it in separate sessions under comparable conditions. Keep every trial rather than selecting only the strongest result. If you change the wording, record it as a different prompt so the comparison remains understandable.

Record observations without overstating the result

Save the exact question, answer text or screenshot, date, product variant, visible environment, and approved reference. The workbook separates the observation from the review status.

Use Pass when the answer meets the recorded criterion. Use Needs fix when it contradicts the source, misses a necessary qualification, or leads to the wrong destination. Use Unclear when the evidence or observation is insufficient. Leave an unperformed test as Not run; absence of testing is not a passing result.

The workbook counts those statuses. It reports a pass rate only across Pass and Needs fix results, and leaves Unclear and Not run visible alongside it. That rate describes the reviewed sample. It is not the share of all customers who received a correct answer.

For a fictional example, a return answer might correctly state the general window but omit the personalized-product exception. Record the omitted condition and source, then assign the fix to the policy owner. Do not label the whole agent unreliable from a single trial or silently mark the answer correct because most of it was accurate.

Test the actual route to human support

Google documents support contact details as a customization setting. Test what a shopper can actually use in the available experience, and verify the destination independently. A configured support address alone does not establish that a chat was transferred, a ticket was created, or an order was retrieved.

Check whether the destination belongs to the intended business, opens successfully, and explains how the shopper can request help. Ask the support owner to verify any response-time statement. Test the route on a phone if that is a common customer device.

When the interface offers a contact route that you cannot complete without creating a real support request, record the limit of your test. Do not manufacture customer issues or send unnecessary tickets simply to make a checklist look complete.

Prioritize and retest material errors

Assign priority based on the business consequence: a wrong price, an unavailable variant, an unsupported product claim, or an incorrect return condition can have a different impact from an awkward greeting. The workbook leaves priority to the reviewer instead of inventing a Google scoring system.

Investigate the corresponding website and product data. Save the source correction, then repeat the original test. Keep the earlier answer and the new result so the record shows what actually changed.

Google offers thumbs-up and thumbs-down feedback within the chat. Use the available feedback control when relevant, alongside your internal issue record. Feedback does not provide a promised correction deadline.

Finish each review with unresolved issues, owners, and the next review date. For results beyond answer quality, use a separate AI visibility measurement framework and keep citations, visits, leads, and revenue distinct. A small answer test supports a concrete correction; commercial impact needs its own evidence.