How does the support model change when your product acts on the user's behalf?

Interviewer's question: "How does the support model change when your product acts on the user's behalf?" Halcyon Desk texts patients to confirm and reschedule visits at Brackenhurst Family Clinic, and can move a patient to a new slot without a person clicking send. Cassia Threlkeld leads product. Averil Nightingale is a patient whose appointment moved on its own.

How to answer this, stage by stage

Nobody is grading whether you know support gets harder with agents. They're grading whether you can say which new support capability to build first, and why the others have to wait.

Let's learn

Halcyon Desk texts patients to confirm or reschedule a visit, and it can move a patient to a new slot without a person clicking send first.

Before Halcyon Desk, Brackenhurst's front desk staff spent about two hours a day on the phone rebooking missed and changed appointments.

Now the agent handles most rescheduling by text in seconds, and a person only steps in for the cases it flags as unusual.

Here is the turn: it isn't that Halcyon Desk sometimes reschedules to a bad time. It's that when it does, there is no fast way for the patient or the front desk to see what happened or why, so even a small mistake turns into a full phone call anyway, at a worse moment than the one it was supposed to prevent.

At its worst: a patient shows up for an appointment the agent quietly moved, or believes it moved when it didn't, the doctor's slot sits empty, and nobody at the front desk can explain what happened without escalating to the vendor's own support line.

The right side isn't a design flaw so much as a design nobody built the left side to prevent.

What I would leave alone: routine appointment reminders, the ones with no rescheduling involved, don't need any of this. Nobody needs an undo button or an escalation path for a text that just says "see you Tuesday at 2."

The lesson: a support model for an acting agent has to be planned in the order things actually break, not the order that felt satisfying to build first.

Now here is the same thing as a story

The short version above is what you'd say defending the build order to the clinic's operations team. Read this one for how the gap actually got found.

Averil Nightingale had been a patient at Brackenhurst for six years, and she'd learned to trust the clinic's texts the way she trusted its waiting room chairs: reliably, without thinking about it.

Halcyon Desk had been live for two months when her Tuesday 2pm checkup got moved to Thursday 9am. She never saw the text, because it arrived while she was in a work meeting with her phone on silent, and by the time she checked it that evening, she'd already half-forgotten there'd been an appointment at all that week.

The first box is not the most exciting one to build. It's the one the other two can't exist without.

She showed up Tuesday at 2pm anyway, out of habit more than certainty, and found the front desk confused too. The system showed her moved to Thursday. Nobody at the desk could say why, because there was nothing to look at beyond that single line. Not what triggered the move. Not whether another patient had been slotted into her old time. Nothing.

A new front desk hire, two weeks into the job, asked the question that stuck: "Can't we just put her back in the two o'clock, since it's obviously still open?" It wasn't obviously open. Halcyon Desk had already offered that slot to someone else the moment it moved Averil, and that patient had already confirmed it.

Cassia Threlkeld's team had built the rescheduling action first, because it was the obvious value: fewer manual calls, faster fills on empty slots. The log showing why an action happened, and a clean way to undo one, sat lower on the roadmap, filed under "nice to have once the core thing works."

Four fields, and none of them existed the week Averil showed up on the wrong day.

The decision I would take back is exactly that ordering. Building the reschedule action before the log made sense in a demo, where nothing ever goes wrong on purpose. It stopped making sense the first Tuesday a real cascade meant nobody, not Averil, not the new hire, not Cassia's own team, could say what had actually happened without pulling raw database records.

Replayed with the log built first: the new hire pulls up Averil's entry in ten seconds. It shows the move, the reason, the other patient now in that slot, and a real undo option that offers both patients a fair alternative instead of just reversing blindly. The call takes ninety seconds instead of turning into an afternoon of confusion and an empty exam room.

I thought building the thing that acts was the hard part, and the log was bookkeeping to add once things settled down. It took one new hire's plain question to see that the log wasn't bookkeeping. It was the only thing that would ever let anyone answer her question at all.

ORDER, spelled out for one appointmentNot a roadmap debate. ORDER is what tells you which support capability breaks first if it isn't built yet.

Month one looks like the least visible work on the roadmap. It's the one everything else depends on.

The fourth item is how you know if the first three are actually working.

The recap, one line per letter: outcome is patient trust and front-desk time, reversibility is undo being hardest to retrofit, dependency is the log unblocking both undo and escalation, evidence is a shadow month before committing a quarter, and rank is log first, reversibility second, escalation third.

And if you want to be sure it really works, try it somewhere elseSame five letters, a personal finance agent instead of a clinic. A different action, the same shape of ranking.

Larkmoor Money runs an agent that moves money between a user's accounts to avoid overdraft fees, transferring funds automatically when a balance dips below a set line.

Mapped onto ORDER: outcome is whether a user trusts what happened to their own money, and whether support gets flooded with "why is my balance different" calls. Reversibility: undo is again the hardest, since a transfer that already cleared and triggered a second automatic transfer elsewhere can't be casually reversed the way a suggestion could have been ignored. Dependency: a clear transaction-level log explaining why each transfer happened has to exist before either undo or a real escalation path can work, since a support agent can't reverse or explain a transfer they can't see the reasoning behind. Evidence: run a shadow period where the agent recommends a transfer and requires one tap to confirm, to learn how often users would have said no, before committing to fully automatic transfers. Rank: the log first, then a same-day reversal window sized to how fast a second linked transfer can be caught, then a dedicated escalation path for cases the log alone can't resolve.

Swap the trigger and it still runs.
Speed: an interviewer caps you at thirty seconds. Say "log first, since undo and escalation both depend on it, then reversible actions, then a dedicated human path," and stop.
Cost: if building a full log this quarter is too expensive, ship a minimal version, just what changed and why, before the flashier reversible-action work, since even a thin log unblocks the ranking that follows.
The model gets better, for real: even if the agent's rescheduling accuracy improves to near-perfect, the log and undo still matter, because the rare mistake that does happen is exactly the one nobody could previously explain.

Where people run it wrong.
They build the acting feature first and treat visibility into what it did as a polish item for later.
They build a dedicated human escalation path before a log exists, so the human being escalated to still can't see what happened.
They measure success by how rarely the agent is wrong, instead of how fast someone can understand and reverse it the one time it is.

How to use it live. When someone asks how support changes for an acting product, ask yourself one thing out loud: if this action turns out to be wrong, can anyone, patient or staff, see what happened without calling a vendor. If not, that's the thing to build first, not last.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0