Questions worth asking.
Answers without the fog.

The live demo is the best way to judge it. The receptionist is designed for natural turn-taking and can be configured around your terminology, but the result still depends on the approved script, voice, and call conditions.

The current browser voice integration supports conversational turn-taking and interruption handling where the voice provider and connection allow it.

Yes. Services, hours, service areas, FAQs, policies, and approved pricing guidance can be included in the business knowledge used by the receptionist.

Yes. Different qualification, scheduling, and routing rules can be defined by service and location. Complex setups are scoped before launch.

It can follow approved transfer and escalation rules. The fallback behavior is also defined in case a person is unavailable.

It depends on the number of services, locations, integrations, and approval steps. We confirm a realistic implementation plan after reviewing the workflow.

Usually services, locations, hours, FAQs, pricing rules, calendar access, escalation rules, and the contacts who should receive notifications.

Yes. We test example calls and edge cases with your team before any live call routing is changed.

No new hardware is required. In many cases you can keep your existing number and forward selected calls, but the exact setup depends on your phone provider.

Yes, when calendar booking is included and the availability rules have been configured and tested.

Often through an automation, webhook, or custom connection. The integrations page states the current connection type without claiming unsupported native integrations.

Yes. The recipient, fields, and delivery method are agreed during configuration.

Pricing depends on call volume and duration, locations, workflow complexity, languages, routing, and integrations. The published prices are starting points, not a binding quote.

Setup is quoted before work begins. It depends on the information, testing, and integration work required for your configuration.

Each proposal defines included usage and any overage rate in writing. Those terms are not hidden behind an unspecified fair-use policy.

Only when recording is enabled, technically supported, and appropriate disclosures and consent handling have been configured. The private browser demo warns users before audio starts.

The approved fallback can transfer, take a message, notify the team, or explain that a person will follow up. It should never invent an answer.

The phone and workflow configuration should include a fallback route. The correct route depends on the existing phone provider and operating requirements.

Yes. Human-request behavior and available transfer windows can be included in the call rules.