On Page Navigation
On Page Navigation
Updated August 26, 2026
A support conversation that happens over text usually happens twice. Once on somebody's phone, and once, badly, in a note typed afterwards by whoever remembers. Twilio SMS for Zoho Desk removes the second half of that by putting the text conversation on the customer record inside your Zoho Desk, where the rest of the team can already see it.
Zoho Desk can already fire SMS notifications outward. The difference here is the return path. A notification goes out and the conversation ends, because a reply has nowhere useful to land. This extension captures the reply and logs it against the record, and it lets an agent send to a group of people at once rather than one notification at a time.
This is the design decision that shapes everything else, and it is the one most likely to surprise somebody arriving with a ticketing mindset. You send from a Contact or an Account, not from a ticket. The conversation belongs to the customer relationship rather than to one case.
In practice that means one issue closes, another opens six weeks later, and the whole text thread is still in one readable place. An agent picking up the new ticket can see what was said last time without opening a closed case or asking a colleague what happened. If your team measures anything by how often customers have to repeat themselves, this is the part that moves it.
The trade is that a text is not a ticket event. If you need every message to sit inside a specific case timeline, this is not the shape you want, and the boundary section further down says so plainly rather than leaving you to find out.
The extension runs inside your own Zoho account. It is written in Deluge, which is Zoho native scripting, so there is no embedded web application and no external service holding a copy of your contact list. We wrote separately about what Deluge is and how it fails quietly if you want the longer version.
You bring your own Twilio account, so the numbers are yours and the rates are the ones Twilio publishes rather than a resold markup. The architecture is identical across the whole extension family, so rather than repeat it here, the Twilio SMS for Zoho CRM documentation covers the data path, the permission model and the no phone home design in full. All of it applies here.
Search and send one to one is the everyday case. An agent is on a Contact, or searches for one, and sends a single message. This is what most of the day looks like.
Bulk send to selected records is the one Desk teams reach for hardest. You filter a list down to the people affected by something, select them, and send all of them the same message. That is what an outage update actually looks like when it is done well.
Send to a specific list is the deliberate version. Instead of whatever happens to be selected on screen, you point at a defined list, so the audience is repeatable and somebody can check it before anything goes out. On a support desk, where bulk sends tend to happen under pressure, that difference matters more than it does on a sales team.
Dynamic text pulls values straight from the Desk record, so a message can carry a name, an account, a reference or a date without anyone transcribing it. Under pressure, transcription is where the errors are.
Reusable templates keep the wording steady across a team that writes very differently, which is worth more on a support desk than almost anywhere else. Customers read a company's tone as a signal of whether it has its house in order, and they are not wrong to.
Scheduled delivery holds a message until a time you pick, which on a desk mostly means two things. Maintenance notices should land the evening before rather than during, and a message to a customer several time zones away should not arrive while they are asleep because that is when your engineers were working. Neither is achievable if sending depends on somebody being at a desk at the right minute.
Support records carry more phone numbers than most, and that is a trap. An Account often carries a main switchboard number while the Contact carries a direct mobile, and a text sent to a switchboard fails silently. No bounce, no error, just nobody answering. Automatic phone field detection shows the agent which number fields the record actually holds, so the choice is deliberate rather than whichever field happened to be first.
You also choose which of your Twilio numbers a message sends from, and on a support desk that decides more than it appears to. Whatever number you text a customer from is the number they will text next time something breaks, whether or not you meant to publish it that way. Send from a number the desk actually watches.
Every message, outbound and inbound, is logged against the record, and inbound replies are logged automatically rather than depending on somebody remembering to file them. Because the message is stored against the Contact or the Account rather than against a single ticket, what you end up with is a relationship history rather than a case attachment.
That is the Desk answer to a problem every ticketing system has. Tickets are episodes. Customers are not. Anything filed only against an episode disappears the moment it closes, which is usually the moment before it becomes useful.
An incident starts, and within ten minutes the queue fills with people asking the same question. Email is the wrong channel for this, because it arrives alongside everything else competing for the same attention. A text arrives.
You filter Contacts down to the accounts affected, select them, and send one message carrying their account name from a field rather than a generic apology. Replies land on the records, so the follow up questions arrive attached to the customers who asked them instead of pooling in a shared inbox somebody has to sort out afterwards.
This is the scenario support teams adopt first, and it is worth building the list before you need it rather than during. Nobody constructs a good filter at eleven at night with a queue climbing.
Time to first response is the number most support teams are judged on, and the honest reason it slips is rarely effort. It is channel mismatch. A customer who raised something urgent is not sitting in their inbox waiting for you to reply to it.
A short text acknowledging the ticket and naming who owns it does the work of a first response, and the reply comes back on the record rather than to a personal phone. If you want that message to fire without an agent clicking anything, that is automation rather than a feature of the extension, and it is exactly the sort of thing managed Zoho automation exists to build.
Confirmations and reminders for anything with a time attached: an engineer visit, a maintenance window, a callback somebody promised. Scheduled delivery sends the reminder the evening before whether or not anyone is at a desk, and the date comes from the field rather than from somebody reading it off a screen and retyping it.
When the customer replies to move it, the reply is on their record, so whoever picks it up can see the original arrangement without asking anybody what was agreed.
A large share of the tickets sitting open are waiting on the customer for something small. A serial number. A screenshot. Confirmation that they tried the thing you asked them to try. Those requests go unanswered by email for days and get answered by text in minutes, which is not a claim about texting so much as an observation about where people look.
The reply comes back to the record, so the ticket moves forward without anybody copying anything from one place to another.
A closed ticket is the cheapest possible moment to ask whether the fix actually held, and almost nobody does it, because it means another email nobody opens. A single line by text a few days later gets an answer.
Because history sits on the Contact rather than on the closed case, that answer is filed somewhere it will still be found. It is also the least intrusive way to catch the problem that was not really fixed, which is the kind that comes back later as a much angrier ticket.
Support holds more sensitive detail than sales does. Account numbers, site addresses, and often the reason somebody is angry. If your obligations say that detail stays inside systems you control, an SMS platform that keeps its own copy of your contact list is out before the demo starts. This runs inside your Zoho org and talks to Twilio with your own credentials, so nothing has to be copied anywhere for texting to work.
It is a claim an administrator can check rather than take on trust. The Deluge is readable, the endpoints it calls are visible, and there is no third party with standing access to your data and therefore no third party whose breach becomes your notification obligation.
Support rarely lives on its own. If billing questions route to Zoho Books or subscription queries to Zoho Billing, the same extension exists for those apps and the same texting behaviour follows the customer across them.
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, which is most of the reason to choose it over a third party tool that connects from outside and calls that an integration.
A Zoho Desk account, and a Twilio account of your own with at least one number able to send SMS to the countries you text. That is the entire prerequisite list. You do not need a developer, and you do not need anything hosted anywhere.
Pricing is a flat organisation price rather than per agent. On a support desk that matters more than it sounds. Per seat pricing on a communication tool quietly pushes you towards giving fewer agents access, and a channel that only half the team can use is worse than no channel at all, because customers cannot tell which half they reached.
Install from the Zoho Marketplace into the organisation you actually use, as an administrator, then connect Twilio with your own Account SID and Auth Token and choose which numbers agents can send from. The step by step version of that setup is written out in the CRM documentation and is identical here apart from the record you test on. Use a Contact.
The step people skip is the round trip. It is easy to confirm a message left and assume the rest works, and the failure that actually bites is a reply that reaches Twilio and never reaches the record. Put a colleague's mobile on a test Contact, send one message, and have them reply from the handset. It takes two minutes, and it is the only test that checks the half of the product you bought it for.
Because you hold the Twilio account, several things are yours rather than ours. You buy and provision numbers. You watch your own balance. You deal with Twilio directly if a carrier starts filtering your traffic. And you complete carrier registration wherever the country you are texting requires it.
In the United States that means A2P 10DLC, and it is not optional. Registration has two parts: a Brand that says who is sending, and a Campaign that says what you send and how people opt in, opt out and ask for help. Both are created in the Twilio Console, and the Brand type you qualify for sets a daily ceiling, quoted against T-Mobile because that is the carrier that limits first. Unregistered traffic is both filtered and charged extra, so putting it off costs money as well as deliverability.
Twilio owns those rules and revises them, so read the Twilio A2P 10DLC overview rather than any summary, including this one. We have also written up the parts of registration that catch people out. Skipping it is the most common reason a new SMS setup works perfectly in testing and delivers badly at volume, so do it before you promise anyone a launch date.
Support teams often assume service messages sit outside consent rules. They do not sit outside them in the way people mean. You still need a basis for texting somebody, you still have to honour an opt out immediately, and you still cannot let marketing drift into a service thread because the number is conveniently already there.
The practical version is short. Record consent on the record. Treat a STOP reply as final. Keep service messages recognisably about service. Because every message is logged on the Contact, you have the audit trail if anyone ever asks what was sent and when, which is a better position than most teams texting from personal phones can claim.
Two decisions are much cheaper to make now than to unpick later. The first is which numbers agents can send from. If every agent can send from every number, the experience is inconsistent and you lose the ability to tell a support thread from a sales one by looking at it. Decide which numbers belong to which team before anybody starts, not after a month of habit has formed.
The second is the template set. A support desk under load reaches for whatever template is nearest, so the templates you ship on the first day are the messages your customers will actually receive for the next year. Write the four or five that cover most of your traffic, have somebody who does not work on the desk read them aloud, and delete the ones nobody will use rather than leaving them there to be picked by accident.
It is also worth agreeing what does not go by text at all. Anything that needs a record the customer can forward, anything with an attachment, and anything you would not want screenshotted. SMS is good at short and urgent and bad at almost everything a long email is good at. Teams that settle this in advance send better messages than teams that work it out one message at a time.
On a desk this question usually arrives about a bulk send, where part of a batch landed and part did not, and that narrows it quickly. A partial failure points at the records: a number field that is empty or badly formatted explains it better than anything else, and phone field detection will show you which records are missing one. A total failure points at the account: either carrier registration is incomplete, which shows up as messages that send but never deliver, or the Twilio balance ran out, which is unglamorous and stops everything at once.
When it is one customer rather than a batch, the Twilio message logs will name the cause. A delivered status means the message is not the problem. An undelivered status carries an error code that is worth reading rather than guessing at. The two answers you get most often are a landline or VoIP number that cannot receive SMS, which is what an office number typed into a mobile field looks like from the carrier side, and a customer who replied STOP at some point in the past. Opt outs are honoured upstream, so everything sent afterwards disappears without an error anybody on the desk ever sees.
A different failure looks like messages that send correctly but never appear on the record. On a desk this usually surfaces as one agent complaining while everybody else is fine, and that pattern is the answer: it is permissions, not messaging. The extension inherits Zoho permissions, so an agent who cannot edit a Contact cannot write history to it either. Compare the two agents' profiles before you look anywhere else.
It is not an omnichannel inbox. Because messages attach to Contacts and Accounts rather than to tickets, an inbound text does not open a ticket, does not update one, and does not stop a response clock. If what you want is SMS as a first class Desk channel with its own queue and its own targets, this is the wrong shape, and it is much cheaper to know that now than three weeks into a rollout.
It is not a marketing platform either. There is no campaign builder, no drip sequences and no attribution reporting, and it is not trying to be a substitute for any of that.
And it does not resell you messaging. Twilio bills you directly at Twilio rates, which is better on price and worse on the day somebody in finance asks why support has a second vendor. Decide that knowingly rather than at the first invoice.
The same extension exists for Zoho CRM, Zoho Books, Zoho Billing, Zoho Projects and Zoho Recruit. The architecture is identical in each. What changes is the record you text from and the job you are doing when you text it.
The full feature list, the pricing and the questions people ask before buying are on the Twilio SMS for Zoho Desk product page. If you would rather somebody else owned the Zoho side of this, including the automation that sends these messages without an agent clicking anything, that is managed Zoho Desk.