What should a founder automate first? Start with the catching up

The obvious candidates for automating first are the chores with names. Invoice reminders, say, or the report somebody pulls together every Friday afternoon. Both are fair picks. They come to mind easily because each already has an owner and a slot in the week, which also means that, for now, they are getting done.

The step nobody puts on the list

The place we look first has no name at all. A client sends a message, and before anyone replies, somebody has to work out where things stand. The WhatsApp thread gets scrolled back far enough to find the last promise made. Then the inbox, in case the client wrote there instead, and after that the CRM, which holds whatever somebody remembered to type into it. Only then does the reply get written. The next time that client gets in touch, the search starts again from the top, since none of what was pieced together got kept anywhere.

We call this rebuilding context. It shows up in any business that delivers through repeated conversations spread across channels that do not talk to each other, so a clinic following up with patients and a recruiter keeping track of candidates end up with the same problem while looking nothing alike.

When we asked the founder of a health habits programme what their largest manual process was, they described exactly this. Participants were reached through in app messages, WhatsApp, email, phone calls, five minute calls with a human companion and longer workshops. After all of that, someone had to assemble each participant by hand, from the interventions already attempted to the next behavioural challenge. The records even had a name inside the company. They were called personas.

That write up is where we would start in almost any business with the same shape. What replaces it is one record per client that every channel writes into as things happen, so the history is already assembled when somebody opens it. A Company Brain does the same for a whole company, reading the tools the team already writes in and citing where each answer came from. The mechanics of the client record get a longer walk in how to stop rebuilding client context before every call.

Count it before anything gets built

First, though, the step needs a number, and the founder supplies every input to it. Take the clients (or patients, or members) the business looks after and multiply by the touchpoints each one gets in a week. Then multiply again by the minutes somebody spends catching up before each touchpoint. What comes out is the hours per week that go into reassembling people.

Here is a made up example, purely to show the shape. Say a coaching business looks after sixty members and talks to each of them twice a week, with six minutes of catching up before every conversation. That comes to 720 minutes, or twelve hours a week, spent before the first useful sentence of each conversation.

Your numbers will be different, and they are the ones worth using, because nobody in the business can argue with a figure taken from their own week. When we run this with a founder, the total is usually larger than they expected. Six minutes sounds like nothing when you only say it once.

That weekly figure is also the input to the cost model, where it sits next to what a build and its running would cost. If the hours come out small, then this is the wrong first project, and possibly not worth building at all.

Your job post already describes it

There is a quicker way to find the step if the business is about to hire. Read the coordinator job post. A posting for a care coordinator or a case manager tends to list every channel the person will work across, then ask them to "track interactions" and "keep notes on each". Some go on to ask the new hire to "summarize for the team", which is the same rebuild done a second time for an audience. Read that way, the posting is the rebuild written down, with a budget already behind it.

None of this means the coordinator should not be hired. The person in that role is there for the conversations that need a human, and a system doing the reassembling gives them more hours for exactly those. We would rather that job existed for the part of the work that involves talking to people.

Reading first, sending later

The rebuild has one more thing going for it as a first project. What it produces is a page somebody reads, and the coordinator still decides what to say and when to say it. If the summary gets something wrong, a person reads it before any client hears about it, which makes it a human in the loop arrangement from the first day.

Automations that act on their own, sending being the obvious one, can come later, once you have watched how the system reads your clients for a while. One of our own send workers had a model driving it. It errored and sent wrongly, then reported a send that had not happened. Nothing with judgement in it goes near a send now; what sends is a small, dull service that confirms each message as it goes.

Put a number on the rebuild first, and build for it if the number is big enough. The invoice reminders can go second.