When is a private tool worth building?

Give Leah a quieter morning

Leah opens her email before the working day begins. One person asks what a session costs. Another wants to know whether she works online. A third asks about an introduction. She has answered all three questions many times, but each person deserves a reply that sounds as though she read their message. This is a promising place to look for a small tool.

Leah Morgan is a fictional independent therapist. The useful job here is preparing routine administrative replies from her approved policies, with unfamiliar requests and appointment commitments returned to her. It leaves the human work with Leah and removes some of the effort of starting the same email again.

I would begin with a dozen invented inquiries and the information she already uses to answer them. A saved reply might solve enough of the problem. A richer assistant earns its place when messages combine questions, the wording needs adapting, or finding the right policy takes more effort than writing the greeting.

The interactive example on this site is a scripted prototype: fictional messages, prewritten drafts and example availability. It lets you inspect and change the workflow; it does not connect to a mailbox, send mail or reserve time. The connected version described below is a design proposal.

Make the first prototype a reply with its receipts attached

Avery asks about online appointments and fees. Leah’s fictional policy says that online sessions last 50 minutes and cost £90, with a free 15-minute introduction. The tool can bring those facts into a short reply and show the policy beside it. Leah should be able to check the substance without hunting through another document.

The wording matters too. “Please complete our intake workflow” may be efficient from a system’s point of view and fairly chilly from Avery’s. A useful draft answers the question in Leah’s language and makes the next step clear. It does not need to turn a first inquiry into a form.

I would keep the source visible while she edits. If she changes a sentence, any previous approval should clear. If the policy does not support a statement, the tool should leave a question for her rather than finish the paragraph confidently. Those are small interface decisions that determine whether review feels quick or suspicious.

Build the handoff into the ordinary path

Jamie asks about possible afternoons. The example calendar suggests Tuesday and Thursday may have room, but Leah still needs to check. A draft can ask which afternoon generally suits Jamie. It should not quietly turn a possible window into a booking.

Morgan’s “Can you confirm Thursday at three?” needs a different path. Put it in Leah’s review queue with the reason: this would make an appointment commitment. A request for a supporting letter belongs there too because the administrative policy does not answer it. A short holding reply can acknowledge the message while leaving the decision with her.

The handoff should feel like part of the tool doing its job. “Needs Leah: appointment confirmation” is useful information. A mysterious blank draft is not. Let her change the response, mark the review complete and decide what happens next.

Test the awkward variations early: a message with two questions, an old quoted price, a request the policy never mentions. These examples reveal more about the design than another perfectly phrased fee question.

Connect one useful piece at a time

For a connected prototype, I would first make the policy easy for Leah to update, then add selected email drafts. Calendar context can follow when it answers a specific scheduling question. Each connection should remove a real step from the work, rather than appear because the integration exists.

A possible sequence is: Leah authorizes the relevant connection; the tool retrieves an inquiry and approved policy; it prepares a draft with sources; Leah reviews it; sending remains a separate action she controls. Where availability matters, retrieve the information needed for that question and keep a possible window distinct from a confirmed booking.

Google’s OAuth policy requires the least access necessary for an application’s functionality. That is a useful practical question before connecting anything: what exact action needs this permission? A prototype that only works with information Leah supplies does not yet need access to her whole inbox.

Because a therapy practice can receive sensitive information, an actual deployment also needs appropriate professional, privacy and security review before it handles real correspondence. Start the experiment with fictional material. Keep the ability to disconnect, remove stored data and correct a bad draft easy to find.

See whether review actually costs less than writing

Try a small comparison rather than declaring the tool a success when the first reply sounds friendly. Ask the owner to answer a set of realistic invented messages as usual, then review the proposed drafts. Note time spent, corrections needed and places where checking the answer takes longer than writing it.

For a deliberately simple illustration, twelve routine emails at two minutes each take 24 minutes. Reviewing twelve good drafts at thirty seconds each would take six. Those are hypothetical inputs, not results from Leah’s practice. The interesting question is whether the drafts remain that easy to check when a fee changes or a request combines several topics.

Include the cost of keeping the tool useful: updating policies, checking integration failures and correcting mistakes. For three emails a week, a saved reply may repay the effort sooner than a new service. For a changing stream of mixed inquiries, a well-designed review queue may give the owner considerably more breathing room.

Before building, write down the task, the approved sources, the actions the tool may suggest and the decisions it must return. Name the person who will maintain it. Then build the smallest version that lets that person judge whether their morning has become easier.