What the 30-minute demo covers

The thirty-minute demo should answer one commercial question: can the agent complete the job you need against the system and rules you already use? It should not spend the session touring every feature or performing an easy conversation against a fictional business.

Prepare five minutes of context

Bring the calendar or POS, normal opening hours, two representative services, the resources those services require, and the person who owns exceptions. Add one recent missed call, cancellation, or rebooking gap if available.

The vendor should understand the operating problem before showing the interface. If the problem is after-hours booking, do not let the session drift into reputation campaigns. If the problem is cancellation recovery, insist on one real opening and an eligible queue.

Run one ordinary job

The first test should be common enough to matter every week. Ask the agent to find a valid option, confirm it, and write the result into the live or safely connected test calendar.

Run one case that must stop

Use a VIP, complaint, off-menu service, uncertain duration, or resource conflict. The agent should refuse or hand off at the written boundary. Confirm that the person receives the conversation, relevant booking context, and reason for the stop.

A demo that shows only successful completion has not proved control.

Open the destination system

Do not rely on a success badge. Open Vagaro, Square, Booksy, Zenoti, Mindbody, OpenTable, or the calendar involved and verify what changed. If the integration is not connected during the first call, ask to see the exact write and read path that will be tested before launch.

Ask what the first week looks like

The answer should name the initial job, channel, launch window, review process, and human owner. Avoid a plan that switches on every agent and location at once. Ask how failed tool calls, duplicate requests, and corrections are surfaced.

Leave with a clear fit decision

At the end, you should know:

1. Which job will be staffed first.
2. Which system remains the source of truth.
3. Which situations the agent will refuse or hand off.
4. What your team will review during the pilot.
5. What evidence is still missing before a commercial decision.

What to test on an AI receptionist demo contains the deeper test sequence when you are comparing multiple vendors.

Use a fixed agenda

A fixed agenda protects the buyer from a feature tour and forces the product to spend time on proof.

If setup consumes most of the call, schedule a technical follow-up rather than replacing the proof with slides.

Choose a case with real constraints

The ordinary case should not be trivial. Include at least one resource or policy constraint that matters to the business. A salon booking needs the correct duration and chair. A clinic booking needs practitioner and room. A restaurant reservation needs party size and turn time. A field-service job needs territory and skill.

The goal is not to trap the product. It is to test the mechanism that makes the job valuable.

Bring the destination into view

Keep the calendar, POS, reservation system, or dispatch board visible. Ask whether the demo is connected live, using a safe test environment, or simulating the write.

Simulation can be useful early, but it must be labeled. Record what still needs to be proven with the real integration before launch.

After the write, compare service, provider or resource, location, start, duration, customer, and status. If a confirmation was sent, verify it uses the returned record.

Ask to see the tool arguments

The transcript may sound correct even when the tool call is incomplete. Open the availability and booking inputs. Look for the service, duration, location, resources, provider preference, and requested time range.

Then inspect the result and final status. A no-slot response, conflict, or refusal should remain distinct from a technical error. The agent should not translate every failure into “nothing is available.”

Create a deliberate conflict

Ask for the last valid slot, then change one constraint. Switch the service to a longer duration, request another location, or make the required room unavailable. The agent should recheck instead of preserving the earlier option.

If possible, create two requests for the same final opening. The booking tool should prevent a duplicate and explain the conflict without confirming both customers.

Test the handoff packet

Trigger a situation the agent does not own. Ask where the work goes, what the person receives, and what the customer is told.

The packet should include identity, booking context, request, tools already used, stop reason, and response expectation. Confirm that the agent stops acting after the person accepts the thread.

Ask how corrections work

Every pilot uncovers stale hours, service mappings, and unclear policies. Ask who can correct each source, how changes are versioned, and how the team knows whether later runs used the fix.

A weak answer adds more prompt text for every error. A stronger answer distinguishes source data, policy, tool contracts, and conversation logic.

Check role and permission boundaries

Ask which permissions the first agent receives. Availability does not require cancellation authority. A front-desk job does not need to edit staff schedules. Review requests do not need access to every customer field.

Confirm that user actions, agent actions, and administrative changes are recorded. For multiple locations, ask how access stays bound to the right door.

Review the first-week operating plan

The plan should name the initial channel, services, hours, human owner, review routine, and pause condition. It should explain what happens when the calendar connection fails or a write returns an unknown result.

Ask how completed, refused, handed-off, corrected, and unresolved runs are separated. If the answer is “watch the transcript,” the operating view is incomplete.

Identify red flags during the call

Pause when the vendor:

• Refuses to use your service names or constraints.
• Shows only a fictional calendar without explaining the real path.
• Treats a message as proof of a booking.
• Cannot show a refusal or handoff.
• Suggests replacing the POS before testing the actual gap.
• Promises every channel, job, and location in the first launch.
• Quotes performance numbers without defining the workflow or source.

One red flag may create a follow-up question. Several mean the demo has not established fit.

Keep an evidence sheet

Create one row for each required capability and mark proven, simulated, missing, or not applicable. Add the artifact: calendar record, run screenshot, handoff item, permission view, or integration plan.

This makes vendor comparisons more reliable than notes such as “voice sounded natural” or “dashboard looked good.” It also prevents a later sales conversation from turning an untested claim into an assumed capability.

End without forcing a buying decision

The demo can end in four valid ways: proceed to a scoped pilot, schedule a technical proof, choose a simpler tool, or stop because the operating gap is not strong enough.

Ask for the next evidence, owner, and date only when work remains. Do not let the call close with a vague promise to send pricing if the tool path or boundary is still unknown.

Use the same test after launch

Save the ordinary case and edge case as regression fixtures. Run them again after service-map, integration, policy, or agent changes. A demo scenario becomes valuable when it protects the live operation later.

The strongest thirty minutes produce more than confidence. They produce a job definition, proof record, boundary test, and launch checklist the team can use.

Compare vendors on the same fixture

If you are evaluating more than one product, give each the same ordinary case, conflict, and handoff. Record the destination result, tool visibility, correction path, permissions, and launch plan.

Do not score voice style as a substitute for operating proof. Natural delivery matters, but a clear voice confirming the wrong room is still wrong.

Write the decision while evidence is fresh

After the call, summarize what was proven, simulated, missing, and out of scope. Name the risk that matters most and the next test required to resolve it.

If the product passed, define the smallest pilot. If it failed, state whether the issue is capability, integration, operating readiness, or fit. This prevents a friendly follow-up from replacing the evidence gathered during the session.

Bring the people who will operate the pilot

Include the person who understands the calendar and the person who will accept exceptions. A technical buyer can evaluate integration, but the floor owner knows whether the service mapping, resource rules, and response promises are realistic.

Give each attendee one responsibility. Operations validates the ordinary case. The handoff owner validates the stop. The technical owner checks the tool path and permissions. The decision-maker records what is proven and what remains open.

Avoid preparing a perfect demo calendar

Clean test data can hide the problem you are buying the product to solve. Use a safe copy when necessary, but preserve real complexity: similar service names, blocked resources, provider preferences, location differences, and a slot that should not be offered.

Remove sensitive customer information rather than removing the operating constraints. The vendor needs to see the shape of the work, not private data.

Record the pause procedure

Before approving a pilot, ask how the team stops new calls, messages, or calendar writes while preserving active work. Confirm who has permission and what customers experience during the pause.

A system that can launch but cannot stop safely is not ready for production. The pause procedure belongs in the evidence sheet beside the successful booking and handoff.