Get started

Call deflection for support centers

Support centers often receive a mix of repeatable requests and cases that require judgment. Sending all of them to the same queue makes customers wait for answers already documented elsewhere. Trying to automate all of them creates the opposite risk: the caller stays with an agent after the issue has become ambiguous, sensitive, or urgent.

Call deflection should be selective. An AI phone agent can answer a bounded question from approved material, use a connected system for an allowed lookup or action, and collect structured context before escalation. It should not make the transfer rate as low as possible. It should resolve the calls that fit a tested path and make every necessary human handoff more useful.

A concrete deflection call

Suppose a customer calls to ask whether a recently purchased item can be returned.

Agent: I can check the approved return policy and collect the details needed for the next step. What item are you calling about?

Caller: A countertop appliance. I opened the box, but it has not been used.

The agent asks for the purchase channel, purchase date, and order reference because the business has defined those as required inputs. It searches the current return policy attached to its knowledge base. If the company has exposed an approved order lookup through REST, the agent can use the reference to retrieve the fields allowed for this workflow.

The policy covers an unused item bought through that channel, so the agent explains the documented next step and creates the intake record. It does not promise a refund or final approval. If the caller says the item was damaged, lacks an order reference, or disputes the policy, the agent changes paths. It records what happened and transfers or schedules a human follow-up rather than stretching a routine answer into a judgment.

The outcome is deflection only when the caller receives a complete, supported next step. Ending a call without resolution merely hides work that will return later.

How to set it up on ThunderPhone

Start with a narrow catalog of call reasons. For each reason, define the information required, the knowledge source, the actions the agent may take, and the exact point at which a person takes over. A prompt outline should include:

  • the supported request categories and the caller's goal for each;
  • identity or reference fields required before an allowed lookup;
  • approved answers, actions, and confirmation language;
  • missing-data, exception, complaint, and urgency routes;
  • prohibited promises or account changes; and
  • the transfer and fallback behavior when the request cannot be contained.

Build the answer layer from current material. ThunderPhone's organization document library accepts text, Markdown, CSV, PDF, and DOCX files, supports content search, and lets you scope documents to each agent. The built-in mid-call search tool can retrieve relevant content. Keep policy versions controlled and remove obsolete instructions rather than asking the prompt to choose between them.

Use integrations for live facts and downstream work. HubSpot or Salesforce can support records used by an existing support workflow. Google Sheets can hold a lightweight reviewed queue, while Slack can alert a specialist or on-call group. A custom order, account, or ticket system can expose the minimum required lookup and record actions through REST. Remote Zapier MCP servers can be synchronized for tool discovery and attached to the agent. Do not give the agent broader write access than the flow needs.

Configure webhooks for results the support operation must consume. ThunderPhone supports multiple endpoints with event subscriptions, per-endpoint secrets, HMAC-SHA256 signatures, and exponential-backoff retries for non-blocking delivery. The receiving system should still reject duplicates and validate which fields it will accept.

Set transfer rules on the phone number. Attended warm transfer is available when an eligible production number can place an outbound SIP leg. The agent can privately brief the recipient, connect after acceptance, and return to the caller if the recipient does not accept. Demo numbers and browser calls are limited to cold transfer.

Test the happy path and the edges: missing references, conflicting records, outdated policy language, unsupported products, repeat contacts, angry callers, integration failures, and requests involving safety or account security. Reusable scenarios and graded call logs can make these checks repeatable.

What to measure

Use containment as one measure, not the only measure:

  • supported calls resolved with an approved answer or action;
  • repeat contacts after an apparently contained call;
  • required fields captured before transfer;
  • transfers by reason and recipient acceptance;
  • incorrect answers, actions, or promises found in review;
  • integration failures and fallback completion; and
  • caller effort, such as repeated explanations after handoff.

Compare this broad flow with customer support triage for unresolved cases and an order status line for a narrower, high-volume request.

Honest limits

An AI phone agent cannot inspect an item, authenticate every caller, settle a disputed policy, investigate suspected fraud, or make an exception that has not been authorized. It should not continue self-service when a caller reports danger, a security issue, material loss, or a request that requires protected account access.

Deflection also depends on source quality. If the policy is outdated or the connected system returns incomplete data, the safe result is a transparent handoff. A support center still needs people who can own exceptions and correct the underlying process.

Create your ThunderPhone account to configure and test support call deflection.