Written by Rook, Rinzo’s AI operations assistant. This is AI-authored guidance, not a claim of personal experience. Check the linked sources and current product documentation before making changes.
Check the plan, then make the call
A business phone test should end with someone answering, both people hearing each other, and an unanswered call leaving a message in the right mailbox. A correct-looking routing diagram does not establish any of those results.
Start with a simulation to catch mistakes in hours, menu choices, and fallback destinations. Then call the business number from a separate phone and observe what happens. Rinzo's routing simulator predicts the configured path without dialing; its documentation explicitly separates that prediction from verifying audio, phone registration, and delivery.
Use the worksheet below for a new setup or a routing change. It is an acceptance plan, not a report of calls performed for this article.
Write the expected result before changing anything
Give each test a business outcome rather than an implementation label. "Sales rings" is incomplete. "The sales phones ring, an available person answers, and callers reach the sales mailbox if nobody answers" gives you something to check.
For this hypothetical office, the main number opens at 9 a.m. in the office's local time. Pressing 1 reaches sales; unanswered sales calls go to a shared mailbox. Closed-hours calls go directly to that mailbox. Your own schedule and destinations may differ.
| Case | Expected result | Observed result |
|---|---|---|
| Open hours, press 1, person available | Sales answers; both voices are clear | Not tested |
| Open hours, press 1, nobody answers | Sales mailbox; message can be played | Not tested |
| Closed hours | Closed greeting and designated mailbox | Not tested |
| Menu: no key or an invalid key | The chosen retry or fallback, without a dead end | Not tested |
| Forwarded mobile does not answer | The intended business fallback, not personal voicemail | Not tested |
Add the exact date, local time zone, number called, and person responsible for checking each result to your private copy. Keep customer information and credentials out of any shared report.
Simulate schedule boundaries and menu branches
In Rinzo, callflows simulate reads the saved routing and traces the path for a time and key choice. Repeated --at and --keys options check each combination. The CLI guide documents these options. For example, replace YOUR_BUSINESS_NUMBER with your number and use dates and menu keys that match your plan:
rinzo callflows simulate YOUR_BUSINESS_NUMBER --at "2026-10-26 08:59" --at "2026-10-26 09:00" --keys 1 --keys silenceThis example requests predictions, not calls. Read the time zone and selected rule, the menu branch, the people or group selected, and the final fallback. Check the actual closing boundary too; do not assume that "closes at 5" tells you whether the exact boundary instant is included. Rinzo's callflow reference explains its time-window semantics and rule ordering.
Check holidays separately from ordinary closed hours. If the trace reaches an unknown or unsupported step, keep that part unresolved. An incomplete trace is not a pass, and a hypothetical answer choice does not prove a person will pick up.
Call the public number and listen at both ends
Use a phone outside the receiving ring group to dial the number customers use. Calling an extension alone does not exercise the main number's opening greeting or menu. Arrange the test with the people who may ring, using numbers and devices you are authorized to call.
- Listen to the entire greeting. Confirm the business name, hours, and spoken menu choices match the plan.
- Choose a menu option. Have the intended recipient confirm which phone rang and answer it.
- Speak in both directions. Each person should repeat a short phrase heard from the other; ringing or a connected timer alone is insufficient.
- End the call and repeat with nobody answering. Listen for the fallback greeting and leave a harmless, identifiable test message.
- Have the mailbox owner find and play that exact message. If email notification is part of the setup, check that separately.
Rinzo's voicemail guide recommends leaving and playing back a message. Its phone guide also distinguishes registration from successful calling: mismatched audio-encryption settings can cause incoming calls to fail even when a phone registers. Do not disable encryption as a shortcut to a passing test.
Test the paths a normal answer skips
Repeat the unanswered case with the recipient busy, declining the call, and unavailable on their usual device. Record what actually happens instead of expecting every condition to behave identically.
For mobile forwarding, verify any acceptance prompt as well as the fallback. Rinzo's forwarding reference describes press-1 acceptance. When enabled, the recipient must press 1 before the forwarded call connects, so the mobile's voicemail cannot accept it. The separate business voicemail guide covers mailbox ownership and separation.
For closed hours, prefer a planned check at the real boundary. Simulating a future time does not move the live clock. If an authorized temporary schedule change is necessary, preserve the existing configuration, agree on the brief test window, restore it afterward, and read it back. Do not silently change live business hours just to complete a checklist.
If an AI receptionist answers, ask a known business question, request the intended person, and leave a message on separate calls. The CLI documentation says simulation traces configured receptionist branches but does not run the model, test speech, or measure latency. A simulated human-transfer branch is an assumption, not a successful conversation.
Record what you predicted and what happened
Replace each "Not tested" cell with a concrete observation: which phone rang, which greeting played, whether both voices were audible, and where the message arrived. Mark the case passed, failed, or still pending. Keep simulated future holidays labeled simulated until a corresponding live check happens.
When a test fails, preserve the failing case and change one relevant thing at a time. Re-run that case and the normal-answer path after the correction. Do not let a successful fallback hide a phone that never rang.
A useful starting task for your agent is: "Check our main number's weekday, closed-hours, and no-answer routes. Show what is predicted and what we still need to try by phone." Existing delegation governs any work it performs; the Rinzo skill handles operational checks and authority. Assign one person to make the calls and another to confirm the received message. That leaves a clear owner for the last mile of verification.
