Voice Notes to Structured Action Plans

The problem

The main cost of running several businesses is routing, not any individual task. A thought that surfaces at 10 PM can touch one entity's payroll cycle, an advisory point for another, and a personal scheduling conflict at the same time. The thinking happens regardless. The cost is stopping, opening the right document, and placing the thought in its correct context.

That friction, multiplied across the fifty to a hundred daily threads that carry operational consequence, is a constant cost in a founder-led organisation. Most operators handle it by not stopping: they lose the thought, or they put it into one undifferentiated note, and the routing never happens.

What was built

A system that accepts a raw voice note or unstructured message — multi-topic, with mid-sentence shifts and half-finished thoughts — and processes it. The first step is routing: the system identifies which entity each thread belongs to and routes it before structuring it. It then structures each thread within its destination: actions with named owners, decisions, blockers, and deferred items.

Output arrives in the format the downstream consumer needs — a memo for a delegated owner, an entry in the project register, a draft email, an update to the company knowledge base. The routing judgment comes from context the system already holds: current live projects, entity priorities, standing escalation policy.

How it works

The system runs in a fixed order, and the order is the point. Structuring a note before knowing which entity it belongs to produces confident output pointed at the wrong place, so routing comes first.

Separate before route

A single note usually carries several unrelated threads. The first step splits the note into its distinct threads, so a payroll question and a scheduling conflict in the same breath are handled as two items rather than one blurred one. Nothing is merged that does not belong together.

Route on held context

Each thread is assigned to the entity and the project it belongs to, using context the system already holds — the current live projects, who owns what, and the standing rules for what escalates. The routing is only as good as that context, which is why the system depends on a maintained knowledge base rather than on re-explaining the business in every note.

Structure into the receiving format

Only after a thread is routed is it structured — into actions with named owners, decisions, blockers, and deferred items — and rendered in the form its recipient actually uses. A delegated owner receives a short memo; the project register receives a register entry; a reply that has to go out is drafted as a draft, not sent. The test is simple: if the recipient has to come back and ask what was meant, the routing or the structuring failed.

Ask rather than guess

When a thread is genuinely ambiguous — an unnamed person, a decision that could sit in either of two entities — the system raises the ambiguity as a question instead of picking an answer. One wrongly routed brief is enough for a downstream owner to stop trusting the briefs, so a held question is cheaper than a confident mistake.

What changed

Processing one of these notes went from roughly two hours of human sorting and drafting to about five minutes, and fewer thoughts are lost: capturing a thought no longer competes with whatever the operator was doing when it arrived.

The human equivalent is a bilingual chief of staff with full cross-entity access — a role that genuinely works at the senior corporate level, but takes 12–18 months before the routing judgment is reliable, and takes the institutional context along when the person leaves. The system applies the organisation's accumulated context immediately, and that context persists.

Where this transfers

The pattern is not specific to a family business group. It fits any operator who holds several areas of responsibility at once — a founder across departments, a managing director across sites, a principal across a portfolio — where the cost is not doing the work but placing each thought in its correct context before it is lost. What has to be fitted to the individual business is the routing map: the list of entities and projects, who owns what, and the standing rules for what escalates. Those are drawn out in the diagnostic conversation before anything is built, because a routing system built on a wrong map routes confidently to the wrong place.

What it required

A maintained, structured knowledge base, because the routing is only as good as the context behind it. A working standard: if the recipient of the structured output has to come back for clarification, the routing or structuring failed. And one firm discipline: when a note is genuinely ambiguous, the system raises the ambiguity as a question rather than guessing, because a wrongly routed brief leads the downstream owner to stop trusting the briefs.

Limitations

Genuinely ambiguous routing still needs the operator to confirm the context. Voice transcripts are processed locally where possible, so raw founder-level commentary does not travel to third-party services unnecessarily.