01

Customers can explain the problem in their own words.

The widget asks for a topic before requesting microphone access. Customers can speak, read captions, mute the microphone and end the call when they are finished. This gives your help centre a conversational route for people who would rather ask than search.

02

Your team chooses the material behind the answers.

Add FAQs manually or import selected Markdown and text documentation from GitHub. Review each source before approving it. When you sync changed repository content, it needs approval again before the agent can use the update.

Start with the product questions you can already answer well. Setup guidance, feature explanations and troubleshooting steps give you a concrete scope to evaluate.

03

Read what customers asked after the call.

The founder dashboard stores conversation transcripts and feedback. Review the questions, spot missing documentation and update the sources the agent uses. Support and sales conversations remain distinguishable in the same workspace.

04

Try a focused support use case first.

Bring a website, a small set of product documentation and a few representative questions. A pilot lets you check the answers and the caller experience before expanding the scope. Access is arranged with the team through a pilot request.

  • Choose a product or help-centre section.
  • Approve the sources the agent may use.
  • Test the questions customers actually ask.
  • Review transcripts before enabling wider access.

Common questions

Is this an AI phone answering service?

The current product provides browser voice conversations on your website. It also has a founder-only outbound phone test and a separate human phone handoff flow. It does not currently offer a public inbound phone number or replace a business telephone system.

Can it look up a customer’s account?

The pilot answers from approved product knowledge. Customer identity verification and account-specific support integrations are outside its current scope.