If you run a cleaning crew out of Jobber or a physio clinic out of Jane App, your management software already sends some texts. Reminders go out, and sometimes "on my way" alerts too. Problems start when a customer replies with "can we push to Thursday?" and the reply goes nowhere useful.
This post covers what built-in texting in field service and practice software usually does, where it runs short, and how to add real two-way texting through an API. We make Ready, so we describe that route in detail. We also say where the native feature is good enough and you should keep it.
What built-in texting usually covers
Most vertical tools treat SMS as a notification channel tied to their own records. The usual set:
- Appointment and visit reminders, triggered by the schedule
- "On the way" or arrival alerts for field techs
- Quote, invoice or booking confirmation links
- On some plans, replies collected inside the job or client record
Features vary by plan and change often, so check your current tier before buying anything. If your software already threads replies into the client record and your volume is modest, you may not need an add-on. That is the honest starting point.
Where the native feature runs out
The gaps that push operators to look elsewhere tend to look like this:
- Replies with no owner. A reply lands in one staff member's notifications or a generic inbox, and nobody is clearly responsible for answering it.
- No outbound beyond templates. You can send the reminder, but you can't easily text a list of past customers about spring maintenance, or start a one-off conversation about a quote.
- Unclear registration. Business texting on US local numbers needs A2P 10DLC registration. Some tools handle it for you. Others leave it unclear whose brand the traffic is registered under.
- One number for everything. You can't pick a number local to each service area, or keep separate numbers for separate clinics.
- Limited compliance controls. Quiet-hours holds, opt-out sync across every send, and litigator scrubbing are often missing or hidden.
If you nodded at two or more of these, an add-on is worth pricing.
Three ways to add two-way texting
| Option | Effort | Replies land in | Best for |
|---|---|---|---|
| Stay native | None | Your management software | Low volume, reminders-first teams |
| Separate texting app beside your software | Low | The texting app's inbox | Teams that want a shared inbox now and can live with two tabs |
| API integration | Developer time | Wherever you build it | Teams that want texting tied to jobs, visits and records |
The middle option is the most common and the least glamorous. Staff keep the schedule in Jobber or Jane and work texts from a shared inbox like the one in the Ready app. Our shared inbox guide for customer service texting covers how to assign and route those conversations so two people don't answer the same customer.
The API route with Ready
Ready has no native Jobber or Jane App integration. Its native connections are GoHighLevel and Close. For other industry software, a developer connects the two systems. Your software's own API or automation tool fires an event, such as a visit booked or a tech dispatched, and that event calls Ready.
Sending one text looks like this:
POST https://api.tryready.com/v1/messages
X-API-Key: <your key>
Idempotency-Key: 6f1c2a9e-3b7d-4e1a-9c55-2d8f0b7a1e44
Content-Type: application/json
{"to": "+12125550199", "body": "Hi Dana, your tech Marco is 20 minutes out. Reply here with any gate code.", "consent_attested": true}The Idempotency-Key stops a retried webhook from texting the customer twice. That happens more often than you'd expect when a scheduler fires the same event more than once. Leave from out and Ready sends from your number closest to the customer's area code.
Opted-out numbers are refused before sending and aren't charged. A text that would land in the recipient's quiet hours is held only if the window opens within 6 hours; otherwise the request is refused with 409 QUIET_HOURS_BLOCK, so have your automation send it again once the window opens. Replies arrive in the Ready inbox, and you can pull them with GET /v1/messages. Endpoints are in the messages API docs and the quickstart. Our SMS API integration walk-through covers retries, batching and testing.
What two-way texting costs: a worked example
Ready's Standard rate is $0.0075 per segment, plus a $0.0045 carrier fee per segment. Replies you receive are billed the same as sends. That all-in figure excludes the optional compliance surcharge: scrubbing and landline validation are $0.003 per segment each when switched on, and both are off by default.
Example assumptions: 300 jobs a month, about 6 texts per job counting both directions (reminder, confirm, reschedule ask, reply, on-the-way, follow-up), and every text under 160 plain characters, so one segment each.
- 300 × 6 = 1,800 segments
- Rate portion: 1,800 × $0.0075 = $14
- Carrier portion: 1,800 × $0.0045
Add one emoji to the reminder template and that message is limited to 70 characters per segment. A 100-character reminder then becomes 2 segments, which doubles the cost of that message. Keep templates plain. For more detail on reply-heavy budgets, see every reply is billed like a send.
Registration on top of that: $25 at submit for the first month, then $25/mo for registration + $2 per number. Most approvals take 2 to 7 days. The first 20 one-to-one texts are free if you use them before registering, and to send any text you need a card and a number ($2 a month, the first month charged when you get it).
For comparison, Twilio and GoHighLevel/LeadConnector cost less per segment. With a raw CPaaS you build the registration flow, opt-out handling, quiet-hours logic and inbox yourself. Pick on what's included, not on the per-segment line alone.
Registration and compliance you can't skip
Registration happens in the Ready app. Pick the campaign use case that matches what you actually send. Reminders and customer care are not marketing.
Clinics have one more rule to follow. Keep clinical details out of texts. "Your appointment is Tuesday at 10 AM, reply C to confirm" is fine. Diagnoses and treatment notes are not. Confirm your own privacy obligations with whoever handles compliance for your practice. Our patient engagement SMS guide goes further.
Ready records your consent attestation for each bulk send and each API send that sets consent_attested: who sent, to how many, and when. It does not store each patient's or customer's opt-in record. Keep that in your management software or intake form. Compliance stays the sender's responsibility. The tooling reduces risk but doesn't remove it. (A contact who signs up on a Ready-hosted opt-in page is the exception: Ready stores that sign-up, with the time, IP address and exact wording, and support@tryready.com can send you a copy.)
If you build the industry software yourself
If you're the head of product at a field service or practice platform, you probably want your customers to get this inside your app. Ready gives each of your customers a sub-account (POST /v1/sub-accounts) with its own numbers and its own 10DLC registration. One shop's bad list then can't damage another shop's deliverability. The question of who registers which brand is covered in 10DLC for SaaS platforms.
The practical takeaway
Start with what your management software already does. If replies have a clear owner and reminders are all you send, stay native. If replies go unanswered, you need outbound beyond templates, or you can't tell whose brand your texts are registered under, add two-way texting. The fastest option is a shared inbox beside your software. The deepest is an API integration a developer can build in days.
To test it, sign up, send your 20 free one-to-one texts to your own team, and register before you text customers.