Build or Buy? Texting Students With Twilio and Your CRM vs. a Platform
Sending a text is an API call. Getting a student to reply and act is not. What building student texting really takes, when building is the right call, and where a platform earns its cost.
Key takeaways
- Building one-way notices with Twilio and your CRM is reasonable. Two-way conversation adds content, reply reading, safety escalation, night coverage, routing and reporting.
- In the US, application texting over ordinary 10-digit numbers goes through carrier A2P 10DLC registration. Twilio says registered traffic is filtered less, and unregistered traffic incurs additional carrier fees.
- Check what you already own before building. Many CRMs and success platforms include texting.
- A common split works well: record-triggered notices in-house, the conversation on a platform, with one opt-out list and one calendar.
"Texting students is an API call." Someone usually says it when a steering committee gets to texting, often someone whose campus already pays Twilio to send two-factor codes. The reasoning is that a vendor would be charging for something IT could wire up in a sprint.
That's half right. Sending a text is an API call, and if all you need is to tell students that registration opens Monday, you can build that with Twilio and your CRM and do it well. Getting a student to reply, reading what she wrote at 11:15 PM, deciding who should see it and making sure she gets to the right office is a different job, and most of that job isn't code. This guide lays out what building student texting really takes, when building is the right call, and where a platform earns what it costs.
What an API like Twilio gives you
Twilio describes itself as a platform that connects communication channels, customer context and AI. For texting, that means phone numbers you control in code, an API to send messages, and, in the words of its own documentation, code on your server that decides what happens when someone texts your number. It's well-documented plumbing, and many campus IT teams already know it.
Think of it as the pipe. What flows through the pipe (who gets texted, what it says, when, and what happens when someone answers) is yours to design, build, staff and maintain.
What building student texting really takes
Here's the full list for two-way texting with students. One-way notices need only the first four rows.
| Piece | What it involves | Who owns it after launch? |
|---|---|---|
| Carrier registration | In the US, application-to-person texting from ordinary 10-digit numbers goes through the carriers' A2P 10DLC registration: your organization as a brand, each use as a campaign, including how people opt in, opt out and get help. Toll-free and short-code numbers have their own processes | IT, and whoever describes each new use |
| Consent records | When each student opted in, how, and the exact wording they saw, kept for as long as your counsel says | Registrar or compliance |
| STOP, HELP and opt-out sync | Honoring opt-out keywords, plus the variations students actually type ("stop pls", "no more"), and syncing every opt-out across every system that texts | IT |
| Quiet hours and caps | Time zones for online and away students, holidays, and a cap on how many texts one student gets in a week from all campaigns combined | IT and every sending office |
| Content | A term's worth of texts is hundreds of messages, written so a student will answer, reviewed by the offices they mention, and refreshed every term | Someone with time to write |
| Reading replies | Free text, typos, emoji, photos and tapback reactions, sorted by topic and by how fast someone should look. One reply can hold two problems | Advisors, or a model you build and test |
| Safety escalation | What happens when a reply contains self-harm language at 2 AM: who's on call, how fast, what the student hears back, and how it's tested | Counseling and the dean of students |
| Routing | Getting each reply to the office that can help, with context, and a way for the student to book | Every office that receives referrals |
| Nights and weekends | Replies don't keep office hours, and the urgent ones don't wait for Monday | A rota, or nobody |
| A staff view | A list of students who need staff attention, with access controls so each office sees only what it should | IT |
| Reporting | Reply rates with clear denominators, actions taken, opt-out rates, by cohort and week | Institutional research |
| Security and privacy | Access reviews, retention, logging, and whatever written agreements your counsel requires for student data under FERPA | IT security and counsel |
| Maintenance | Carrier rule changes, delivery failures, number reputation, students who change phones, and a fresh roster every term | IT, indefinitely |
Twilio's own documentation says registered traffic gets less filtering and higher throughput, and that unregistered traffic from its 10-digit numbers incurs additional carrier fees. Registration isn't a formality: it affects how reliably your messages arrive and what they cost.
On the legal side, texting rules in the US (the TCPA among them) and carrier policies both turn on consent and opt-out. What applies to your messages depends on what they say and who sends them, so treat this as a list of questions for your counsel, not answers.
The parts teams underestimate
Writing
Most build plans budget for code and forget words. A single term of weekly texts to a first-year cohort, split by goal and by a few points in the calendar, runs to hundreds of messages. Each one has to be short, ask for one thing and be easy to answer. Someone has to write them, someone has to check that the tutoring center really is open until 9 on Thursdays, and someone has to do it again in January.
Reading
The first time you send a question to a few hundred students, you'll get back "k", "c", a thumbs-up reaction, "who is this", a photo of a bill, and one message that says "honestly idk if i'm coming back next semester". Your system has to tell those apart, every time, including the last one at midnight on a Saturday.
Safety
Any system that invites students to text will eventually receive a message that needs a person right away. Building that path means agreeing it with counseling, testing it before launch, and testing it again whenever an on-call number changes. It's the row in the table you can't skip, and the easiest one to leave until late.
When building makes sense
Building is a good choice in some situations, and we'd say so to a campus that asked us:
- One-way notices triggered by a record. A hold was placed, a payment is due, registration opens tomorrow. Your SIS or CRM knows when to send; a few templates, a STOP handler and registration cover it.
- You have an owner for years, not a semester. A named engineer and a named content owner, budgeted past the first term.
- The scope is narrow. One office, one use case, a reply path that's mostly "yes" or "no".
Before building anything, check what you already own. Many student CRMs and success platforms include texting; EAB, for example, lists two-way SMS among Navigate360's features. Turning on a feature you already pay for usually beats building one. And emergency alerts belong in your campus's dedicated mass-notification system, not in a homegrown texting service.
Where a platform earns its cost
A platform is worth paying for when students are expected to reply and something should happen when they do. You're not buying the API call. You're buying the content, the reading, the routing, the safety path and the staff view, already built and already tested on students, plus someone else carrying the carrier rules and the maintenance.
| If this is true | Then |
|---|---|
| Messages are one-way and triggered by a record change | Build, or switch on what you already own |
| Students are expected to reply | Buy, unless you can staff replies, nights included |
| Replies might contain safety language | Design and test escalation with counseling, whichever way you go |
| More than one office will send | You need one calendar and one opt-out list either way |
| You want to start this term | Buy; carrier registration and content alone take time |
The split many campuses end up with
Build or buy is rarely all or nothing. A common and sensible arrangement: IT keeps record-triggered notices in-house, or in the CRM that already sends them (a hold was placed, a payment is due, a registration window opens), and a platform carries the two-way conversation with a defined cohort. Three things make the split work.
- One opt-out list. The homegrown sender and the platform both check it before every send. Settle with counsel how far a single STOP should reach.
- One calendar. Notices and nudges both go on it, so the hold reminder and the study nudge don't land in the same hour.
- Separate numbers, clearly introduced. Students should know that one number sends notices and the other one talks with them, and the first message from each should say who it's from.
Done this way, IT owns what it's good at, record changes and reliable delivery, and nobody has to staff a Saturday-night inbox with an engineer.
Questions to answer before you build
- Who reads replies on a Saturday night, and what do they do with one that's urgent?
- Who writes the two hundredth message, and who rewrites the first one in January?
- Who owns carrier registration when you add a new use?
- What happens when a student texts STOP to one office's number and then gets a text from another?
- Who answers when a student asks what you've stored about them?
- What will you report, with what denominator, and who checks it?
If every answer has a name next to it, building may be the right call. If several say "we'll figure it out", that's the cost a platform is meant to cover.
The conversation layer, if you buy it
Journey is the conversation part of this list. It texts students first over SMS and iMessage, with nothing to install, from nudges built on each student's goals, a few texts a week, inside the windows the student chooses, never more than one proactive text a day and nothing in quiet hours. Students can text STOP at any time to opt out, or PAUSE to take a week off. It decides what each reply is about and how fast it needs a person, routes safety language to people through the escalation process your campus sets, answers campus questions from a resource base gathered at setup, and gives staff a dashboard of the students who need attention, with themes instead of transcripts. Students change when, how often and about what they hear from Journey in plain text ("can my nudges come at 7pm", "pause my nudges for a week"), and every change is said back to them. It holds any queued nudge a student has already received, and it doesn't answer a tapback reaction or a plain "ok" as if it needed a reply.
It works next to the systems you already run, connecting where they offer an API or an export. Journey processes student data only under a written agreement with the institution, as a school official with a legitimate educational interest, and SOC 2 certification is in progress. On your side, expect about eight hours of staff time to set up a 100-student pilot, most of it gathering the campus resource details Journey can't find publicly. In a typical week of the University of New Haven pilot, 74% of students replied to Journey or acted on a nudge.
If your team decides to build one-way notices in-house and use a platform for the conversations, that's a sensible split, and we're happy to help draw the line. The pipe was never the expensive part. The 2 AM reply is.
Frequently asked questions
Can we build our own student texting system with Twilio?
Yes, especially for one-way notices triggered by a record, such as a hold or a payment due date. For two-way conversation you also need consent records, opt-out handling, quiet hours, a large library of messages, reply reading, safety escalation, night and weekend coverage and reporting.
What is A2P 10DLC registration?
It's the US carrier system for verifying application-to-person texting from standard 10-digit numbers. You register your organization as a brand and each use as a campaign, including how people opt in, opt out and get help. Toll-free and short-code numbers have their own processes.
Do we need consent to text students?
Consent sits at the center of US texting rules, including the TCPA, and of carrier policies. What applies depends on what your messages say and who sends them, so ask your counsel, and keep records of when and how each student opted in.
When does buying a student texting platform make sense?
When students are expected to reply and something should happen when they do: a reply read at night, safety language routed to a person, a student booked with the right office. If you need to start this term, buying also avoids building content and registration from scratch.
