Connect the work that happens after the click

Every workflow we build has a person in it, and the approval step is the default rather than a setting you can pay extra for. An agent assembles the draft; somebody reads it; only then does it go anywhere. That is not caution for its own sake — it is what makes the rest of it safe to run quickly, because the failure mode of an unsupervised system is not that it is wrong once, it is that it is wrong a hundred times before anybody looks.

We run our own outbound through the identical loop, which is how we know where it breaks rather than where we imagine it breaks. Neither founder sends an email by hand; nothing sends without a yes.

The usual objection is that the main system is closed, so nothing can connect to it. In practice almost every business platform can put a scheduled report somewhere on a timetable, and a handful of those reports is enough to assemble a real operating picture without touching an API at all.

The engineering that makes this hold up is deeply unglamorous and matters more than the idea. Scheduled exports arrive with a title block above the data, so a loader that assumes the first row is the header breaks the first time somebody reconfigures the report — find the header row by reading it instead. And different configurations of the same platform label the same column three or four different ways, so map by what a column means rather than by where it sits. Do both and a differently configured export from the same system lands in the same dashboard without a code change.

It is worth knowing the small constraints too. Document connectors frequently read spreadsheet and document formats but not CSV or PDF, which quietly decides what format your scheduled export has to be in.

Where several sources feed one system — a form, a mailbox, an agent watching work as it happens, a person typing — they all land in the same review queue rather than writing directly. Somebody accepts or rejects, and a manual edit always beats an automated one. That last rule sounds obvious and is the one most often got wrong: a sync that overwrites a correction somebody made by hand teaches everyone to stop making corrections.

Dashboards then read from the result, so the number on the screen has a traceable path back to the thing that produced it rather than being assembled fresh by whoever was asked for it.

Three properties do most of the work of making automation trustworthy, and none of them is glamorous enough to appear in a sales deck.

A re-run after a partial failure sends only what did not land the first time, because the half-failed job is the normal case rather than the exceptional one. There is a switch that stops everything, owned by you, that does not require us to be awake. And the publish step refuses outright if a placeholder is still sitting in the content — a refusal is cheap, and a placeholder published live and indexed is not hypothetical; we have found one on a site before we started working on it.

The same principle governs the drafting: a draft that fails a check is regenerated rather than hand-patched, so the generator never learns that a near miss is good enough.

The pattern repeats across very different businesses. The same handful of answers typed again and again. A status report assembled by hand every week because the platform will not produce the version anyone wants. Follow-up that happens for whoever comes to mind rather than for everyone. Scheduling that costs three emails. Documents generated by copying last month's and editing it. Data moved between two systems by a person who has learned to be careful.

None of that is judgement, and all of it is expensive. The gain from automating it is not that a machine talks to your customers — it is that the thing that happened most weeks now happens every week, and the person who used to assemble it is doing something that needed them.

Judgement calls, relationships, and anything that needs professional advice. Where the work is document and deadline handling in a regulated context, that is what we build — the paperwork process around decisions your team and your advisers make, which is workflow automation and not legal advice, and we are explicit about the line.

We are also not the right people for a project whose goal is to remove the person from a decision that should have one. The approval step is the product.