Integrating voice agents with Twilio, Exotel and your CRM

The model gets the attention, but integration is where voice-agent projects succeed or stall. A voice agent has two integration surfaces: the telephony side, which carries the audio, and the systems side, which lets it act. Both have well-trodden patterns and predictable pitfalls. This guide lays out the reference architecture, the choices on each side, and the checklist we use before any pilot.

Reference architecture

Telephony: SIP, Twilio or Exotel?

If you have a carrier SIP trunk or a PBX that speaks SIP, connect it directly to the media server and keep your numbers and routing unchanged. If you need numbers, recording and programmable routing quickly, Twilio is the global default and Exotel is common for Indian numbers and compliance. The choice affects per-minute cost and regional latency more than capability; India-based callers benefit from an India-region provider and media server. Keep the provider account in your name so usage cost is transparent.

Systems: wrappers, not direct access

The agent never touches your database. Each action it can take is a small function with a clear contract: check availability for a doctor on a date; book a slot; look up an order by phone number and last four digits; send a payment link. The wrapper enforces business rules (buffers, blackout periods, eligibility) and permissions, logs every call, and returns structured results. This is what makes actions safe and testable; it is the same MCP-style tool pattern used across our agents.

CRM and scheduling systems we integrate

• CRMs with APIs: HubSpot, Salesforce, Zoho, our own TheEazy CXM
• Scheduling and practice management: vendor APIs where they exist; wrappers over databases where they do not
• Hospital information systems: scoped wrappers, often over HL7/FHIR interfaces
• Loan management and collections systems: outcome write-back and consent flags
• Order and commerce: Shopify, custom OMS, courier tracking APIs
• Legacy systems with no API: wrapped first, sometimes as the first phase of modernization

Identity and consent

Identity is a tool like any other: match the calling number to a record, then require a second factor before any account detail is read. Consent status, do-not-call flags and channel preferences are read from the system of record on every call and enforced by the wrapper, not by the prompt. Recording announcements are configured per jurisdiction.

Reliability patterns

• Timeouts and fallbacks on every tool call: the agent says it cannot confirm and offers a callback rather than waiting
• Idempotency: booking and payment actions are safe to retry
• Circuit breakers: when a system is down, the agent switches to message-taking mode automatically
• Staging first: wrappers are tested against a staging copy with recorded calls before production
• Write-back: every outcome is written to the system of record so staff see one truth

Messaging after the call

Confirmations and links go by SMS or WhatsApp through the WhatsApp Cloud API. Utility templates are approved in advance. The message references the call so the customer sees continuity; the same identity is used across channels, which is where a voice agent and a WhatsApp agent share infrastructure.

A worked example

A service business ran an Exotel number into a legacy CRM with no API. The integration phase built a wrapper over the CRM database with four functions (find customer, list slots, book, reschedule), each enforcing the company's buffer and territory rules, and tested it against a staging copy with recorded calls. The voice layer attached to it in week three. When the CRM was later replaced, only the wrapper changed; the agent did not. That separation is the reason to build the wrapper first.

Team and timeline

Integration is the first two to three weeks of a six-to-ten-week voice build, owned by an integration engineer with the telephony engineer. Where the system has no API, add a week for the wrapper. The rest of the team, conversational AI engineer and delivery lead, joins once the wrapper passes its tests. Scope and starting prices are on the voice agent and pricing pages.

Before you start: a checklist

• Telephony: SIP trunk details or provider account; numbers to route
• Systems: API documentation or database access to a staging copy
• The list of actions the agent may take and the rules each enforces
• Consent, do-not-call and preference fields in the system of record
• Messaging templates for confirmations
• Regions for media and speech near your callers

Testing the wrapper before the voice layer

Every wrapper ships with a test suite run against a staging copy: happy paths, rule violations that must refuse, timeouts, duplicate submissions and permission failures. Then recorded calls are replayed through the dialogue layer against the same staging system, so the first real call is not the first test. When the CRM vendor changes an API, the suite fails first, and the wrapper is fixed before any caller notices. It is unglamorous work and it is why the pilot week is boring, which is the goal.

Observability across both surfaces

One trace per call links the telephony leg, per-stage latency, every tool call with its inputs and outputs, and the outcome written back. When a call goes wrong, the trace shows whether it was the network, recognition, the model or the CRM. Dashboards report tool error rates alongside resolution, so a failing integration is visible before callers complain. The trace is also the audit record for regulated clients, retained per the same schedule as recordings.

Choosing regions and providers for Indian callers

Indian inbound minutes are inexpensive on domestic providers, and India-region media servers cut round trips substantially against a default US region. Exotel and similar providers handle Indian numbering, DND registries and compliance features natively; Twilio is stronger for global reach and programmable routing. Many deployments use a domestic provider for Indian numbers and Twilio for international, behind the same media server, with routing by number. Keep both accounts in your name.

Glossary

• SIP trunk: the connection carrying calls between your carrier or PBX and the media server
• Wrapper: a small permissioned function over a system the agent acts in
• Idempotent action: safe to retry without duplicating a booking or payment
• Circuit breaker: automatic switch to message-taking when a system is down
• Write-back: recording the call outcome in the system of record
• Utility template: a pre-approved WhatsApp message for confirmations

Mistakes we see

Integration mistakes are expensive because they surface in the pilot: building the voice layer first and simulating actions; giving the agent database credentials instead of wrappers; no timeouts, so a slow CRM becomes a silent call; provider accounts in the vendor's name; and confirmations sent as marketing templates that get rejected. Sequence the wrapper first and test it on recorded calls.

Questions clients ask

• Can the agent work with two systems at once? Yes; each is a wrapper, and the dialogue composes them.
• What if our CRM API is rate-limited? Prefetch on connect and cache briefly; the wrapper enforces limits.
• Do we need a new phone number? No; existing numbers route over SIP or through your provider.
• How are secrets handled? In a vault, never in prompts or code; per-environment credentials.
• Can we replace the CRM later? Only the wrapper changes; the agent and telephony stay.

What good looks like after 90 days

A ninety-day review checks wrapper error rates, timeouts and circuit-breaker events, confirms write-back completeness against the CRM, and reviews provider costs on accounts you hold. Stable wrappers are what let the agent expand to new intents cheaply.

Related reading

What is an AI voice agent?, Latency in voice AI and API Development & Integrations for the wrapper discipline.

Build the wrapper first, keep provider accounts in your name, and treat every action as a function with rules. The voice layer is then the easy part.

For decision-makers: ask to see the wrapper's test suite and the trace of one real call before you sign off a pilot. If both exist, the integration was engineered; if not, the demo was the integration.