Start with questions your customers actually ask
Build your test set from recent enquiries, staff notes and recurring telephone questions. Remove unnecessary personal information before sharing examples with colleagues. Write down the expected answer or outcome before calling: otherwise, a fluent response can sound satisfactory even when it contradicts your opening hours or promises something you cannot provide.
Keep the first review small enough to investigate properly. Six calls can cover two ordinary questions, one unclear request, one callback, one handover and one disabled service. Use natural phrasing rather than reading your business information word for word. Confirm current call and usage limits before arranging repeated tests.
- Ask: “What time do you close on Saturday?”
- Ask a routine question with an answer already in your configured business knowledge.
- Ask: “Can I change the thing I arranged for next week?” without explaining what it is.
- Request a callback, ask to speak to someone, then separately request an unavailable service.
Judge the outcome, not just the voice
Voice and language choices affect the customer experience, but a pleasant conversation is not proof that reception is working correctly. Check whether the answer was accurate, whether the caller understood the next step, and whether any promised action has an observable result. A callback request is not the same as a completed conversation with your team.
For every call, keep a simple review record: test question, expected outcome, actual response, supporting evidence, issue owner and retest result. Use call notes if recordings or transcripts are unavailable; optional recordings and transcripts follow your settings and retention. Mark a test as passed, failed or needing investigation rather than relying on an overall impression.
- Compare factual answers with the current configured information.
- Check callback details in the resulting record.
- For a handover, confirm that the intended recipient actually received the call.
A hypothetical review: find the precise failure
Hypothetical example: a small salon configures its Saturday closing time as 4 pm, accepts callback requests and uses a UK number for handovers. Booking workflows are not enabled. The owner asks, “Are you open until five on Saturday?” A correct answer should give the configured 4 pm closing time rather than simply agreeing with the caller.
The owner then asks, “Book me in at three.” Because booking is disabled, the test should fail if the response claims an appointment is confirmed. A satisfactory outcome would explain that the booking cannot be completed through this route and offer a configured alternative, such as a callback. The review record should preserve what was actually said, not soften it into “booking query handled”.
- Record the exact unsupported confirmation, if one occurs.
- Check the business knowledge and enabled workflow settings.
- Correct the relevant setting or raise the issue, then repeat the same wording.
Check handovers and service boundaries separately
Test handover to your configured UK number or SIP destination with a colleague ready to receive it. Compare the caller’s experience with the recipient’s account. If the call does not arrive, check the destination configuration before attributing the problem to the spoken response. Test opening-hours answers separately from transfer availability; one passing does not prove the other works.
Only test orders or bookings as available services when the relevant NeroWeb or NeroBooking workflows are enabled. WhatsApp requires assisted onboarding, verification and authorisation before activation. NeroGym, NeroTrade and NeroConnect integrations support enquiries and callbacks, not guaranteed autonomous transactions. If payment comes up, check that the route uses secure checkout links: customers must not speak full card details to the AI.
Turn each issue into a correction and a repeat check
Separate incorrect source information from an unexplained behaviour. Outdated opening hours call for a configuration correction. A correct configuration followed by an incorrect answer needs investigation. A missing callback record or failed handover needs evidence of the attempted action, not just a rewritten greeting.
Retest the original question after every correction, then try one natural variation. Your observable success check is straightforward: the answer matches the configured facts, the resulting record or handover matches the request, and no unavailable action is described as completed. Escalate unresolved issues to the team with the test time, wording, expected result and available evidence, excluding unnecessary customer information.
GOOD TO KNOW
Common questions
Do I need recordings to review the calls?
No. Structured call notes and checks of the resulting records can support a review. Use optional recordings or transcripts only in line with your settings and retention.
Should I deliberately ask confusing questions?
Yes, but make them realistic. An incomplete request tests whether the conversation avoids unsupported assumptions. Do not judge success solely by whether the AI gives an immediate answer.
Does a successful booking enquiry prove bookings work?
No. An enquiry, a callback request and a confirmed booking are different outcomes. Test the enabled workflow and inspect the resulting record before treating a booking as completed.
What should I test again after changing settings?
Repeat the failed question and a differently worded version. Also recheck any closely related outcome, such as closed-hours wording after changing opening hours.