Text Answering Service: What It Costs, and How to Automate It With AI

Every business that takes enquiries by phone eventually notices the same thing: a lot of people would rather text. They don't want to sit in a queue, they don't want to leave a voicemail, and they will happily type two sentences at 9pm and wait for an answer in the morning.

The awkward part is finding out what serving those people costs. The human answering-service industry prices by the minute, which is a telephone idea, and most of the AI vendors in this space won't publish a number at all. So this piece does the part nobody does. First, what a text answering service costs, using rates the providers publish themselves. Then how to build one, on the current Voiceflow model rather than the one that existed when this guide was first written.

One thing up front, because it shapes everything below: I have removed a claim this article used to lead with. It said SMS gets a 98% open rate. That number is everywhere, and it is not measurable. More on why in a moment, because the reason is useful to you as a buyer.

What a Text Answering Service Costs

There are two ways to buy this, and they are priced in different units, which is most of the reason the comparison feels slippery.

The Human Option Is Priced by the Minute

Outsourced answering services bill for operator time. Specialty Answering Service is the one provider in this cluster that publishes a full rate card:

Billing is by the second, month to month, with no setup fee and a 14-day trial capped at 200 minutes. That is genuinely transparent, and it is the exception. Most competitors in this space route you to a sales call and describe their packages as affordable without printing a figure anywhere.

Note what the unit does to text, though. A minute is a measure of someone talking. When an operator handles a text conversation, you are paying for the minutes they spend typing and waiting, which is a worse deal than voice for the same amount of information. A five-message exchange spread over an afternoon can consume more billable operator attention than a two-minute call that resolves the same question.

Automation Is Priced by the Message

Build it yourself and the cost structure changes shape entirely. The message transport is the only part that scales with volume, and Twilio publishes that rate: "SMS (U.S.) starts at $0.0083. Price per outbound message sent to U.S. long codes."

So a fifteen-message conversation, generous for a booking or a quote request, costs you something in the region of twelve cents in carrier fees. On top of that sits a platform subscription and model inference per turn, both of which are fixed or near-fixed rather than proportional to how busy your week was.

Run the two against each other on a real volume. Two hundred text conversations a month, averaging four minutes of operator attention each, is 800 minutes: on the table above that lands on the 1,000-minute plan at $1,199, or about $6 per conversation. The same 200 conversations as an automated flow cost roughly $25 in messages plus your platform and model spend. The gap is not marginal, and it widens every month the volume grows.

That is the honest case for automation here, and it is a cost-structure argument rather than a quality one. Which brings me to the claim I cut.

Why the "98% Open Rate" Figure Should Not Be in Your Decision

This article used to open by telling you SMS gets a 98% open rate, better than any email campaign you will ever run. I have removed it, and I would treat any vendor still quoting it as a small signal about the rest of their numbers.

SMS has no open tracking. There is no pixel, no beacon, and no carrier read receipt for application-to-person traffic. Email open rates exist because you can embed a tracking image; text messages have nothing equivalent. What the carrier hands back is a delivery receipt, which tells you the message reached the handset and nothing whatsoever about whether a human looked at it.

So the 98% is not a measurement. It is an estimate inferred from delivery confirmations and lock-screen behaviour, and when you chase it to its source there is no study underneath, only vendors citing other vendors. Some of the pages defending it will concede in the small print that it is an informed estimate rather than an instrumented metric.

None of which means text is a weak channel. It means the true argument for it is delivery and reach, which are measurable, plus the fact that people answer on their own schedule. Buy it for the cost structure and the response behaviour you can actually observe in your own numbers, not for a statistic that cannot exist.

The Cost Nobody Mentions: A2P Registration

If you are sending to US numbers from a long code, you have to register. Twilio's US messaging guidelines confirm that domestic long-code messaging requires A2P 10DLC registration, covering both your brand and each campaign.

Budget time for it rather than money, and read the compliance terms before you launch. The carrier penalties are real and they pass straight through to you: Twilio documents a $1,000 pass-through fee for program evasion techniques such as snowshoeing or unauthorised number recycling, and up to $10,000 per unique instance of content that violates the T-Mobile code of conduct. That is not a reason to avoid the channel. It is a reason to keep your opt-in language clean and your sending patterns boring.

Text, Voice, or Voicemail

Most people arriving at this decision are really choosing between three things, only one of which is free.

Voicemail is in the table because it is the honest baseline. It is what most businesses are actually using, and the cost of it is invisible, which is exactly why it survives.

The channel question matters too. If your enquiries are urgent and emotional, a phone agent is the better first line and text is the follow-up. If they are logistical, which covers most quoting, booking and status questions, text is the better primary and it is cheaper to run. Several of the vertical guides get specific about this: property management, plumbing, medical, insurance, HVAC and taxi dispatch all have different tolerances for a text-first front door.

What to Look For

Whether you buy or build, these are the things that separate a text answering service that works from one that annoys people.

It remembers the conversation. Text is asynchronous. Someone will reply four hours later, mid-thread, with a single word. If the system has lost the thread by then, it is worse than voicemail. Session state that survives long gaps is the requirement, not a nice-to-have.

It knows a returning customer. The phone number is the identity. Recognising it and skipping the questions you already have answers to is the cheapest possible improvement to the experience.

It writes for the medium. A 160-character segment is one billable message. Longer replies get split, cost more, and read badly on a lock screen. Answers should be short because the channel is short, not because the model was told to be terse.

It knows when to stop. A text agent should hand off to a person on anything it cannot resolve, and the handoff should carry the transcript so the human is not starting over. The small business answering service guide walks through how that escape hatch usually gets wired.

It writes to your systems. Captured details that sit in a log nobody reads are not captured. The agent should push to your CRM or scheduler in the same turn, and appointment booking is usually the highest-value integration to wire first.

How to Build One

Here is the current shape of this build. If you want the deeper channel-specific walkthroughs, the Twilio SMS integration guide covers the messaging layer in more detail and the Make.com guide covers the no-code glue.

Built an AI Chatbot That Texts Customers

Worth saying plainly: Voiceflow has no native SMS channel. Text is a custom channel, which means you connect it through the API, and you need something sitting between Twilio and Voiceflow to do it. That has not changed. What has changed is the vocabulary and the endpoints, so if you followed an older version of this guide, this is the part to re-read.

Build the Agent as a Playbook

The qualification conversation belongs in a Playbook, which is a task-scoped sub-agent with its own instructions, tools and model. Your main agent routes to it based on the description you give it. This is the part that replaced the old single-step approach, and the practical benefit is that a playbook handling text can have different instructions from one handling voice while sharing the same knowledge and variables.

Give it instructions that suit the channel:

You qualify inbound enquiries over SMS.

Collect, in this order, one question per message:
1. What kind of business or property the enquiry concerns
2. What they need help with
3. An email address to send a written summary to

Rules:
- One question per message. Never stack two.
- Keep every reply under 160 characters.
- Plain sentences only. No bullet points, no markdown, no currency symbols.
- Use what they already told you to make the next question specific.
- Do not offer next steps until all three answers are stored.
- If they ask something you cannot answer, hand off rather than guess.

That formatting rule is not decoration. Markdown renders as literal asterisks in a text message, and it is the most common thing to get wrong when a flow built for web chat is pointed at SMS.

Then declare the three variables the playbook fills, and attach an API tool from Project, CMS, Tools to write the result to your CRM or sheet. An API tool is a saved HTTP request with templated variables, which is what the old guide called an API block.

Connect Twilio

Point your Twilio number's incoming-message webhook at your middleware endpoint and set the method to POST. Use a Messaging Service rather than a bare number: it manages the sender pool and gives you somewhere to attach your A2P campaign registration.

Twilio will send you the sender in From and the message text in Body. Respond 200 immediately with an empty or minimal body, before you do any Voiceflow work. Skip that and Twilio's own status responses can surface as messages to your customer, which was the single most confusing failure in the original version of this build.

Run the Turn

Two transports are current. The v4 interact socket at general-runtime.voiceflow.com/v4/interact/socket is the preferred one and the right choice if you want streaming. For an SMS webhook you do not need streaming, because the customer gets one text back per turn, so the HTTP path is simpler to operate:

POST https://general-runtime.voiceflow.com/v2/project/{projectID}/user/{phoneNumber}/interact/stream?environment=production

Authorization: VF.DM.xxxxx
Content-Type: application/json

{
  "action": { "type": "text", "payload": "{{Body}}" },
  "variables": { "channel": "sms" }
}

Two details that cost people hours. Session variables go at the top level of the body on this endpoint, not nested under state. And the target environment is a query parameter now: V2 renamed versions to environments, so an old versionID: production header is the wrong shape.

Use the customer's phone number as the user ID. Voiceflow keys session state on that ID, so conversation position and every variable you have collected persist between texts with no work from you. That is the whole reason this architecture holds up on an asynchronous channel.

Take the assistant's reply out of the returned traces, keep the text traces and drop the rest, then POST it back to Twilio's messages endpoint.

Handle State Deliberately

You can read the full session with GET /state/user/{phoneNumber}, which returns three keys: variables, which holds everything your playbook and tools have written and is the only one you should touch; stack, the runtime's execution context; and storage, which is internal. An older version of this guide listed a fourth called turn. There is no such key.

If you need to seed context from outside a turn, for example writing an account tier you already know from the phone number, PATCH /state/user/{phoneNumber}/variables merges keys in, creates ones that were never declared, and persists immediately. That is cleaner than the two-branch new-user-versus-returning-user router the original build used, because you can write what you know and let the playbook read it.

One auth note: state routes want the project-bound VF.DM. key. The workspace-level VF.SA. key returns a 500 on them, and the error does not explain why.

Middleware: Two Reasonable Choices

Make.com is a fine option and it is what the templates below use. Its case is that a non-developer can maintain it, and the webhook, router and HTTP modules cover this whole flow visually.

The alternative is a small function of your own, on whatever you already run. Its case is that this is about forty lines of code, you get real error handling and retries, and you are not paying per operation on a path that fires on every inbound text. If you have anyone who can maintain a serverless function, that is the version I would run in production.

Ready-made Make.com blueprints for the two halves of this flow, the CRM write and the Voiceflow-to-Twilio connector, are available as importable scenarios:

• Make.com CRM API workflow
• Make.com Voiceflow and Twilio connector

If you would rather start from a working agent than a blank canvas, the lead generation solution covers the qualification pattern this build implements.

Where This Does Not Pay

Automating text answering is a volume play, and it is worth being clear about the floor.

If you get twenty enquiries a month, build nothing. The registration work alone will cost you more attention than the calls do, and a human answering them personally is a competitive advantage at that size rather than a cost.

If your enquiries are genuinely urgent, text is the wrong primary channel and no amount of good design fixes that. Someone with a burst pipe is going to call.

And if you cannot yet answer the questions people ask, automation makes the problem faster rather than smaller. Get the answers written down first. That is what the knowledge layer is for, and it is the part people skip.

The version worth building sits between those edges: enough volume that per-conversation cost matters, questions that are logistical rather than emotional, and a real system on the other end to write the answers into.

Next Steps

Price your own situation against the table above before you build anything. Take last month's enquiry count, guess honestly at how long each exchange takes, and put it against the $1,199-per-thousand-minutes line. If the number makes you wince, you have your business case, and the build in this guide is a weekend of work.

If you would rather see the pattern running before you wire your own, book a demo and we will walk through a text agent handling a live enquiry end to end.