On Page Navigation
On Page Navigation
Updated August 26, 2026
Twilio SMS for Zoho CRM adds two way texting to the records you already work in. You send from a Lead, Contact or Account, the reply comes back to that same record, and the whole thread stays inside your Zoho CRM. Nobody has to open a second application, and nobody has to remember to copy a conversation back into the system afterwards.
That last point is the reason the extension exists. Texting customers is easy. Texting customers in a way that the rest of the business can see, six weeks later, when a different person picks up the account, is the hard part, and it is the part most SMS tools quietly leave to you.
The extension runs inside your own Zoho account. It is built in Deluge, which is Zoho native scripting, so there is no embedded web application and no external service holding a copy of your customer list. If you want to understand what Deluge is and how it behaves, we wrote a separate piece on what Deluge actually is and how it fails quietly.
Practically, running natively changes three things. Your data never leaves Zoho, so a vendor breach somewhere else is not your problem. Your admin can read the automation and see how it is wired rather than filing a support ticket to ask. And the extension inherits Zoho permissions, so a user who cannot see a record cannot text it either.
You bring your own Twilio account. The numbers are yours, the messaging rates are the ones Twilio publishes rather than a resold markup, and if you ever stop using the extension the numbers and history stay with you. The trade is that you are the Twilio account holder, which means number provisioning and carrier registration are yours to complete. More on that below.
Search and send one to one is the everyday case. You are on a record, or you search for one, and you send a single message. This is what a rep uses twenty times a day.
Bulk send to selected records handles the case where you have filtered a list view down to the people you want and you want all of them to get the same thing. Twelve customers affected by a delivery delay, say, or everyone whose renewal falls this month.
Send to a specific list is the more deliberate version. Rather than whatever happens to be selected on screen, you point at a defined list, which means the audience is repeatable and somebody can check it before you send. If you have ever sent a bulk message to the wrong filter, you will understand why these are separate features rather than one.
Dynamic text pulls values straight from the record. A message can carry a first name, a renewal date, an invoice amount or any other field without anyone retyping it, which is what makes bulk sending survivable rather than obviously mass produced. Personalization here is not a marketing flourish, it is accuracy: the date in the message is the date on the record.
Reusable templates keep the wording consistent between people who write very differently. In most teams there is one person who writes beautifully and one who writes in fragments, and the customer cannot tell which of them is the company. Templates solve that without anyone being told their writing is the problem.
Scheduled delivery holds a message until a time you choose. This matters more than it sounds. Reminders belong the evening before, not at four in the afternoon when somebody finally gets to the task, and a message to a customer three timezones away should not arrive at two in the morning because that is when your team was working.
Real CRM records rarely have one phone number. There is a mobile, a work number, sometimes an assistant, sometimes a field somebody added three years ago that half the team fills in. Automatic phone field detection finds the number fields present on the record rather than assuming a single hardcoded field, so you choose which one you are texting rather than discovering afterwards that it went to a switchboard.
You also choose which of your Twilio numbers a message sends from. That is what lets a support line and a sales line stay distinct, or a regional number stay regional, rather than everything arriving from one anonymous number that customers learn to ignore.
Every message, outbound and inbound, is logged against the record. Inbound replies are logged automatically rather than needing anyone to file them, which is the difference between a history that is complete and a history that reflects how diligent the team was feeling that week.
Lead to Contact conversion mapping deals with a specific and annoying failure. In Zoho CRM a Lead becomes a Contact, and anything attached only to the Lead can be left behind at that moment. The conversation you had while qualifying somebody is exactly the conversation you want when they become a customer, so the mapping carries it across rather than stranding it on a record nobody opens again.
A lead fills in a form and a rep texts within a few minutes, from the lead record, using a template that already carries the person's name and what they enquired about. Response rates on a text sent inside ten minutes are not comparable to an email sent the next morning, and everyone in sales already knows this. What stops teams doing it is not willingness, it is that texting from a personal phone leaves no trace.
Here the reply lands on the record. When a different rep picks the lead up on Thursday, the conversation is there. When the lead converts, the history follows. And when somebody leaves the company, their phone leaves with them but the conversations do not.
Confirmations and reminders sent from the record, with the appointment date pulled from a field rather than retyped by somebody reading it off a screen. Customers reply to reschedule, and because the reply is on the record the person handling it can see the original booking without asking.
Scheduled delivery is what makes this practical at all. Reminders go out the evening before regardless of who is at a desk. If you want the reminder to fire without a human initiating it, that is automation work rather than a feature of the extension, and it is the sort of thing managed Zoho automation exists to build.
An invoice reminder by email competes with a hundred other emails. The same reminder by text gets read, and often gets a reply saying it was already paid, which is information you wanted anyway. Dynamic text carries the amount and the due date so nobody transcribes a figure incorrectly.
If the money lives in Zoho Books or Zoho Billing rather than CRM, the same extension exists for those apps. See Twilio SMS for Zoho Books and Twilio SMS for Zoho Billing, where the dunning case is covered directly.
If your obligations say customer contact details do not leave systems you control, most SMS platforms are out before the demo starts, because holding a copy of your list is how they function. This runs inside your Zoho org and talks to Twilio using your own credentials, so the list stays where your policy says it stays.
That is a claim you can verify rather than take on trust, which is the point. An admin can read the Deluge and see exactly which endpoints are called. There is no vendor with standing access to your data, and no vendor whose own breach becomes your notification obligation.
Candidates answer texts and ignore email, particularly candidates who are currently employed and not checking a personal inbox during the day. Interview confirmations, reschedules and reminders all work better over SMS, and the whole thread belongs on the candidate record rather than on a recruiter's phone. That case is covered by Twilio SMS for Zoho Recruit.
Because it is Deluge inside your org, an admin can read what it does, see how it is wired, and reason about it alongside everything else they maintain. That is a real difference from an embedded application you can only configure through somebody else's settings screen and can only diagnose by asking. If you are already running several Zoho apps under Zoho One, this behaves like the rest of your stack rather than like a guest in it.
A Zoho CRM account, and a Twilio account of your own with at least one number capable of sending SMS to the countries you text. That is the whole prerequisite list. You do not need a developer, and you do not need anything hosted anywhere.
Installation comes from the Zoho Marketplace. You connect Twilio with your own credentials, choose which numbers are available to send from, and the first message can go out the same day. Pricing is a flat organization price rather than per user, so adding the whole team later does not change the bill. That is deliberate: per seat pricing on a communication tool quietly encourages you to give fewer people access, which is the opposite of what you want.
The three steps below are the whole of the setup. Most teams are through them inside an hour, and the part that takes longest is not the software.
First, install from the Zoho Marketplace into the organisation you actually use. Installing into a sandbox or a personal developer org is the most common false start, because the extension then works perfectly on records nobody else can see. Check the org name before you confirm the install, and install as an administrator, so the extension can create the fields and related lists it needs.
Second, connect your Twilio account. You need the Account SID and Auth Token from your Twilio Console and at least one SMS capable number already bought on that account. Enter them in the extension settings and choose which of your numbers should be available to send from. If you run a sales line and a support line, decide now which teams see which, rather than after everyone has spent a month texting from whichever number happened to be first in the list.
Third, text a real record and watch the reply come back. Put a colleague's mobile on a test Lead, send one message from the record, and have them reply from the handset. You are checking three things at once: that the message left, that the reply arrived, and that the reply was written to the record rather than sitting in Twilio. If only the third one fails, the first two will still make the setup look healthy, which is why this test uses a phone somebody is holding rather than a delivery report.
Once that round trip works, everything else is configuration rather than plumbing. Templates, dynamic fields, number selection and scheduling all sit on top of the connection you have just proved.
Because you hold the Twilio account, a few things are yours rather than ours. You buy and provision numbers. You complete carrier registration where your destination country requires it, which in the United States means registering your business and your use case before volume messaging works properly. You watch your own Twilio balance, and you deal with Twilio directly if a carrier filters your traffic.
None of that is hard, but it is real work and it happens before your first send rather than after. Skipping registration is the single most common reason a new SMS setup appears to work in testing and then delivers badly at volume. Budget an afternoon for it, and do it before you promise anyone a launch date.
If you are texting people in the United States from an ordinary ten digit local number, you have to register for A2P 10DLC before that traffic is treated as legitimate. This is a carrier requirement rather than a Twilio one. It applies to anyone sending from an application, and as far as the United States carriers are concerned every message a Twilio number sends is from an application, including the ones a person typed by hand.
Registration has two parts. A Brand says who is sending. A Campaign says what you send and how people opt in, opt out and ask for help. Both are created in the Twilio Console. Which Brand type you qualify for depends on who you are: a business with a tax ID registers as a Standard or Low Volume Standard Brand, while a sole trader or an individual registers as a Sole Proprietor Brand.
The Brand type sets your ceiling, and the ceiling is quoted per day against T-Mobile because that is the carrier that limits first. A Sole Proprietor Brand runs one Campaign and is capped around a thousand message segments a day. A Low Volume Standard Brand allows up to five Campaigns and roughly double that. A Standard Brand starts there and rises, depending on the trust score the carriers assign you. Your practical total across all United States carriers is higher than the T-Mobile figure, but the T-Mobile figure is the one you will hit.
Two things are worth knowing before you promise anyone a launch date. Unregistered traffic is not only filtered, it also attracts additional carrier fees, so putting registration off costs money as well as deliverability. And toll free numbers and short codes sit outside A2P 10DLC entirely, with their own verification process, so changing number type does not let you skip this. It only changes which queue you are standing in.
Twilio owns the current rules and revises them more often than anyone would like, so check the Twilio A2P 10DLC overview rather than trusting a summary. We have also written up the parts of registration that catch people out the first time.
Texting people who did not agree to be texted is both a legal problem and a fast route to having your numbers filtered. Record consent on the record, honour opt out requests immediately, and keep marketing messages inside whatever permission you actually collected. This is not a limitation of the tool, it is the same obligation you have on any channel, but SMS punishes carelessness faster than email does.
Because every message is logged on the record, you have the audit trail if somebody ever asks what was sent and when. Use it.
Three causes cover almost everything. The number field on the record is empty or badly formatted, which phone field detection will show you. Carrier registration is incomplete, which shows as messages that send but never deliver. Or your Twilio balance ran out, which is unglamorous and more common than anyone admits. Check them in that order before assuming anything more interesting is wrong.
If all three of those are clean, work outward in this order. Open the Twilio message logs and find the specific message, because a status of delivered means the problem is not sending at all, and a status of undelivered carries an error code that names the cause. Then check whether the destination is a landline or a VoIP number that does not accept SMS, which is common on records where somebody put an office number in a mobile field. Then check whether that person has ever replied STOP, because opt outs are honoured upstream and will silently drop everything you send afterwards.
A different failure looks like messages that send correctly but never appear on the record. That is almost always permissions rather than messaging. The extension inherits Zoho permissions, so a user who cannot edit a record cannot write history to it either. If one person's messages log and another person's do not, compare their profiles before you look at anything else.
Finally, if delivery is fine for most recipients and poor for one carrier, that is filtering rather than a fault. Filtering usually traces back to incomplete registration, to wording that reads like one of the categories carriers block, or to volume that jumped suddenly on a number with no sending history. Twilio can tell you which of the three it is. The extension cannot, because by then the message has already left.
It is not a marketing campaign platform. There is no drip sequence builder, no landing page tooling and no attribution reporting, and it is not trying to be a replacement for any of that. If you want long running nurture campaigns with branching logic, you want a campaign tool and this is not it.
It also does not resell you messaging. Twilio bills you directly. That is better on price and worse on convenience, and you should choose it with your eyes open rather than discover it at the first invoice.
The same extension exists for Zoho Desk, Zoho Books, Zoho Billing, Zoho Projects and Zoho Recruit. The architecture described here is identical in each; what changes is the record you are texting from and the job you are doing. The support side is written up separately in the Twilio SMS for Zoho Desk documentation.
The full feature list, pricing and the questions people ask before buying are on the Twilio SMS for Zoho CRM product page. If you would rather somebody else owned the Zoho side of this, including the automation that fires these messages without anyone clicking, that is managed Zoho CRM.