Phony

Availableapp.erp.io/phony/agents

Agents

An agent is a brief, a voice, a set of things it may do, and somewhere to hand over to. The brief is the part that decides whether it is any good.

Brief
Compiled from your knowledge
Voice
Selectable
Actions
Explicitly granted
Handover
To a person or a booking

The brief

The brief is the agent's account of what your company is and does. It is compiled from the knowledge you have given it — usually your website — rather than typed by hand, which is why the first thing to check when an agent sounds vague is the brief rather than the prompt.

An agent that cannot say what your company does has an empty brief, not a broken corpus

This is the single most misdiagnosed failure in the module. The corpus can be fully ingested and the brief still empty, because compiling the brief is a separate step that can complete having produced nothing. The compile step reports success either way. If the agent is vague about your own business, look at the brief first — the fix is usually to recompile it, not to re-crawl your site.

app.erp.io/phony/agents
Reception

Voice + chat · live on 1 number, 3 sites

Try itSave
BriefVoiceActionsHandover
Save agent
The agent configuration. The brief on the left, behaviour and handover on the right.

Prompt variables

An unsupplied variable deletes its whole line, silently

If the agent's instructions contain a placeholder — a transfer number, a business-hours string, a booking link — and no value is supplied for it at run time, the entire line containing it is dropped. Not left blank: removed. The agent then behaves as though that instruction never existed. In one case the line that vanished was the one restricting when a transfer could be offered, and the agent promised a transfer it had no way to make. Check that every variable an agent references actually has a value.

The behaviour is now covered by a test, but the shape of the failure is worth carrying with you: a missing variable does not produce an error or an obviously broken sentence. It produces a coherent agent that is missing one rule.

Actions

An agent can only do what it has been explicitly granted. Nothing is implicit.

ActionWhat it doesNotes
AnswerRespond from the brief and knowledge.Always available.
QualifyAsk the questions you specified and record the answers.The questions are yours.
CaptureCreate a person and a lead.Routes to CRM — see [People](/docs/modules/phony/people).
BookOffer and take a booking.Needs a calendar configured.
TransferHand the live call to a person.Needs a destination and a window.
Request a callbackQueue a call back to somebody who just called.Consent re-checked at dial time.

Handover

The most valuable configuration in the module and the one most often left empty. An agent with nowhere to hand over to is an agent that ends every good conversation with a promise somebody has to keep manually.

  1. Set the destination — a person, a rota, or a number. Configure it in Team.
  2. Set the window. Outside it, the agent should take a message rather than attempt a transfer that will not connect.
  3. Set the criteria. What has to be true before a conversation is worth interrupting somebody for.
  4. Test it by calling your own number at 9am and at 9pm. Both paths should behave sensibly.

What this does not do

No custom voice cloning

Voices are selected from a set. You cannot clone a specific person.

No multi-agent routing

One agent answers a given number or site. There is no menu that routes to different agents.

No mid-call knowledge editing

Changes to the brief apply to the next conversation.

No arbitrary tool calling

Actions are the fixed set above. An agent cannot call an API you define.

Questions

How many agents can we have?

Several — typically one per brand or per number.

Can the agent speak other languages?

It follows the caller within the languages the voice supports. Test before relying on it.

Can we script it exactly?

You can constrain it heavily. An entirely scripted agent is an IVR, and worse than one.