Case study: a worker that texts real people
Appointment Reminder Texter is the shape where a mistake reaches a stranger. What contact rules actually do, and why this one earns a narrow send stage.
The three earlier walkthroughs get progressively riskier: a read-only brief that changes nothing, support triage that writes drafts, lead qualification that drafts on an event.
This one is different in kind. It **sends, to people outside your company, without anyone reading it first.** That makes it the clearest test of whether the controls actually hold.
As before: an implementation walkthrough, not a customer story. No invented companies and no invented outcome figures.
The job, and one honest caveat
Appointment Reminder Texter reaches calendar and messaging. Its job sentence: *texts your clients a day-before reminder for their appointments, cutting no-shows dramatically.*
That last clause is the publisher's claim, not a measured result, and it is worth naming as such. Reminder messages reducing no-shows is a well-worn idea in scheduling-heavy businesses, and whether it holds for your clients is something your own booking data answers, not a kit description.
Why this shape is the hard one
| Drafting worker | This worker | |
|---|---|---|
| Who sees a mistake | You, before anyone else | The recipient, immediately |
| Reversible | Yes, delete the draft | No, the text arrived |
| Detected by | You reading drafts | A confused reply, or nothing |
| Wrong recipient costs | Nothing | A stranger receiving your client's appointment details |
| Right control | The instruction | Contact rules |
Row four is the specific risk. This is not a worker that might write something awkward; it is a worker that might tell the wrong person where someone will be tomorrow.
The loadout
| App | Level | Why |
|---|---|---|
| Calendar | Read | Tomorrow's appointments and who is on them |
| Messaging | Write | Sending the reminder |
Two apps and exactly one write. No email, no CRM, no files. The app firewall makes that a property of the worker, so the question "could it email someone" has the answer "it holds no email access" rather than "the instruction says not to".
Where contact rules do the actual work
Write on messaging says the worker may send. It says nothing about to whom, and that distinction is the entire safety story here.
A calendar is a messy source of humans. Tomorrow's events contain, alongside genuine clients:
- internal colleagues on shared bookings
- a vendor or contractor on a joint meeting
- an ex-client whose record was never cleaned up
- someone added to an invite by a client, whom you have never met
Every one of those is an address the worker could technically reach. Contact rules are what limit sends to the intended set, and they refuse a blocked recipient outright rather than dropping it quietly, with the refusal landing on the receipt.
The reason this is a control rather than an instruction line is the standard one: an instruction is a request the model weighs against the task in front of it, and the task in front of it is "remind the attendees". A filter is not.
The schedule
Once daily, in the afternoon, covering tomorrow.
| Option | Verdict |
|---|---|
| Daily, mid-afternoon | The job. Enough notice to rearrange, not so early it is forgotten |
| Hourly | Sends duplicates unless carefully guarded; no benefit |
| 24 hours before each appointment | Precise, and needs per-event triggering rather than a schedule |
| Morning of | Too late to be useful for anything but a nudge |
Schedules run wall-clock in your own time zone, so a 3pm send stays 3pm through daylight saving rather than drifting to 2pm for half the year. For a worker whose whole value is "the day before", that is not a detail.
Free allows one schedule per worker, hourly or daily, which is exactly this.
What it costs
Roughly 2 tool calls per appointment: read the event, send the message, plus one call to list the day.
| Appointments tomorrow | Tool calls | Share of Free's 500 |
|---|---|---|
| 10 | ~21 | 4% |
| 40 | ~81 | 16% |
| 100 | ~201 | 40% |
| 250 | ~501 | Over Free, needs Pro |
A clinic or salon doing under about 100 appointments a day fits on Free. Past that the daily cap binds and Pro's 5,000 is the answer. Model tokens bill separately at provider list price with no markup.
Note how differently this scales from a triage worker: cost tracks **appointment volume**, not schedule frequency, because one run does all of tomorrow.
Roll it out narrow
This is the worker that most justifies the staged rollout, and specifically the narrow-send stage that other workers can skip.
- Read-only for a week. It cannot send. Read the receipts and check who it would have texted. This is where you discover the colleague, the vendor and the stale contact.
- Send to yourself only. Contact rules limited to your own number. You see the real message, at the real time, in the real format.
- Narrow send. One day of the week, or one practitioner's bookings.
- Full.
Step 1 is the one people skip and the one that matters. The list of people a calendar would have you text is genuinely surprising the first time you read it.
Where it should stop
- It should not reschedule. Read on calendar, not Write. Rescheduling is a different worker and a much larger risk.
- It should not include sensitive detail. "Your appointment tomorrow at 3pm" is a reminder; the reason for the appointment is not something to text. Use redaction if your event titles carry clinical or commercial detail, which in health and legal contexts they routinely do.
- It should not chase. One reminder is a service; three is a nuisance you have automated.
- It should not run without consent. Whether you may text someone is a legal question in most jurisdictions, and it is prior to any of this.
The reasonable objection
"Automating outbound messages to clients is exactly the thing that goes viral when it goes wrong."
Right, and that is the correct level of caution. Two things make it manageable rather than reckless: the blast radius is bounded by contact rules that the model cannot argue past, and the rollout above means the first real send happens after you have read a week of receipts showing exactly who would have received one.
The residual risk is honest: a correctly-scoped reminder to a genuine client, at the right time, with the wrong appointment on it, because the calendar was wrong. No control fixes a bad input, and the mitigation is that the message is a reminder rather than an instruction, so a client who spots the discrepancy simply replies.
FAQ
How do I stop an AI worker texting the wrong people?
With contact rules, which decide which people a worker may reach and refuse a blocked recipient outright. They are enforced by the platform rather than by the instruction, so a worker whose task is "remind the attendees" cannot reason its way into messaging someone outside the set.
What access does the Appointment Reminder Texter need?
Read on calendar to see tomorrow's appointments and who is on them, and Write on messaging to send. Nothing else. It cannot reschedule, because it holds no calendar write access.
What plan do I need for appointment reminders?
Free handles up to roughly 100 appointments a day within its 500 tool calls, since one run covers all of tomorrow at about 2 calls per appointment. Higher volumes need Pro. See /pricing.
Should this worker send automatically or draft?
Drafting a hundred texts for review defeats the purpose, so this is a genuine send-automatically job. That is precisely why it deserves the narrow send stage: read-only first to see who it would have texted, then yourself, then a subset.
Does it reduce no-shows?
The kit's description says so, and that is the publisher's claim rather than a measured result. Whether it holds for your clients is a question your own booking data answers after a few weeks of running it.