← Notes

A one-person operation has to be designed as one

My opinion: the mistake was not losing those two conversations, it was designing a flow that only works if I am available.

When I lost those conversations, the first explanation that came to me was my own: I was not there. It is true and it is insufficient, because the next question is why the system depended on my being there.

My opinion is that one-person operations tend to be designed as if they were small company operations — same flow, same promise, fewer people. It is not the same thing. A small company has redundancy: if one person misses it, another sees it. One person alone has none, and a flow without redundancy that promises a fast reply is promising on behalf of someone who might be bathing a baby.

What I argue for is not lowering the bar. It is moving the bar. Instead of asking how long I take to reply, asking what the system delivers on its own while nobody replies: what it collects, what it books, what expectation it creates, and how it hands the conversation back to me in a shape that is still usable later.

There is also a limit I want to record honestly. A more flexible and automated agentic pipeline is the direction that interests me, and I have no measurement of how much of those conversations it would recover. It is a working hypothesis, not a proven solution, and I will treat it that way until I have data.

What is not a hypothesis is the diagnosis: the bottleneck in my service is neither the platform nor the AI. It is the assumption, built into the flow, that someone is on call.