§ 01 Abstract
The front desk is the roadmap.
ObjectiveFit Skrypt Health to the way your clinic actually runs, without making you wait for a release.
ApproachAsk what’s behind the request. Build the smallest change that fits. Put it live on your line. Check it helped.
ResultA medical clinic rotates its on-call doctor every week, with swaps. Six days after the first message, urgent after-hours calls were following that schedule.
TakeawayShipping in days isn’t an engineering trick. It’s a decision about whose time matters.
§ 02 Background
Every Friday, re-routing the phones.
The clinic’s doctors take turns being on call after hours. Who’s on call changes every week.
Skrypt Health already sent urgent after-hours calls to a person. But it sent them to one phone number, and that number had to match whoever was on call that week. Keeping it matched was a manual job.
Figure 1. How the workaround worked, and where it broke.
Nobody did anything wrong. The setup just depended on one person remembering, every single week.
She told us in one text, on a Tuesday afternoon. No form. No portal. No vote.
§ 03 Methodology
Ask, build small, ship whole, check.
A request describes a symptom. So we asked what was behind it.
- Ask. Same afternoon: how often do swaps happen, who makes them, and what counts as urgent? Swaps most months, any doctor, and the clinic’s existing rules.
- Build. An on-call schedule for this clinic in the Client Hub. Urgent after-hours calls go to whoever is on call, with the transcript. Routine after-hours requests still wait for the desk to confirm in the morning.
- Ship. Live on the clinic’s own line, with a short note on how to enter the schedule and make a swap.
- Check. Not done until the clinic confirms it worked on a real night.
What didn’t change: your escalation rules decide what’s urgent, and your front desk still confirms everything the AI captures. Speed never costs you a person in the loop.
§ 04 Results
From message to in use, in six days.
Counted from their first message to their confirmation. Not from when we started building.
Day 0, message received. Day 3, built and tested. Day 4, live on their line. Day 6, in use at the desk.
Figure 3. From the clinic’s first message to their confirmation.
Now, a patient calls after hours with a worsening fever. The AI recognises it as urgent under the clinic’s rules and hands the call to whoever is on call tonight, with the transcript. A patient calling to move next week’s check-up is captured for the desk to confirm in the morning.
The urgent call follows the schedule, not last Friday’s phone settings.
| Aspect | Before | After |
|---|---|---|
| The task | Update forwarding by hand every Friday | Set the schedule once; a swap takes a moment |
| Who gets the urgent call | Whoever the number last pointed to | Whoever is on call, with the transcript |
| Getting it changed | A ticket in a queue, a future release | A message to a person; live in six days |
§ 05 Discussion
Whose time matters.
A workaround that lasts a quarter costs your front desk every single day.
We’d rather absorb the work on our side than ask you to absorb it on yours. That means saying yes to small, specific requests, building them whole, and treating “they’re using it” as the only definition of done.
It’s more work for us. It’s the job.
Tell us once. We’ll take it from there.
§ 06 Limitations
One request, one clinic.
- Scope varies. Not every request ships this fast, and some shouldn’t.
- Safety first. Anything touching how your desk confirms what the AI captures is tested with you before it goes live.
- Dates from messages. First message to confirmation, not when work began or code was merged.
§ 07 Conclusion
Tell us what’s in the way. We’ll build it.
Skrypt Health is built with the clinics that use it, one request at a time.
When your front desk asks, it becomes our priority. And it comes back working, in days.