Hobfolk
Method

Anyone can automate.
The hard part is proving it happened.

Four mechanisms, each of which exists because something failed without it. None of this is novel. All of it is the difference between automation that works in a demonstration and automation that works in August.

Start a conversation
You go home. It doesn't.Every promise gets a row and a due dateAnswered the same day, not the next working dayA drawing before the quoteUnverifiable is never a passNine desks, one address eachNothing is sent that a human cannot read backThe folder exists before you price itYou go home. It doesn't.Every promise gets a row and a due dateAnswered the same day, not the next working dayA drawing before the quoteUnverifiable is never a passNine desks, one address eachNothing is sent that a human cannot read backThe folder exists before you price it
What we actually sell

Systems first. Automation is what makes them run.

We do not train your team. They learn from working next to something competent, which is how anyone has ever learned a job.

Automating a broken process gives you a broken process that runs faster and complains less. Most disappointing AI projects are exactly this: the tooling worked and the underlying operation was never designed.

So the first thing we deliver is not software. It is the operating design — what the departments are, what each is answerable for, where the boundaries between them sit, which decisions require a person, and what “finished” means for every recurring piece of work. Written down, in English, and yours to keep.

Then we build the desks that fill those roles, connect them to what you already use, and run them.

01

Role definitions

What each function owns, and — harder and more valuable — what it does not. Most operational failure lives in the gaps between two roles that both assumed the other had it.
02

Job descriptions that are executable

Written precisely enough that software can perform them and a human can audit them. If a description is too vague to automate, it was too vague for the person doing it too.
03

The decision gates

The three or four points where a human must decide, made explicit and enforced at the chokepoint rather than in a policy nobody reads.
04

Digital partners for your team

A departmental counterpart per person, carrying the chores. Not a chatbot — a colleague with a remit, an address, and things it is accountable for.
05

The continuity layer

Every promise becomes a row with an owner and a due date, in the same breath it is made, swept by something that does not depend on anyone being awake.
06

The verification layer

A department whose only job is to disbelieve the others and check at the far end. Yours to run as well as ours.
The honest version of the claim

Ten times the output, and where that number comes from

“10×” is a number people put on slides, so it is worth saying where ours comes from and where it does not apply.

It does not mean your estimator becomes ten estimators. It means the throughput of a function rises by roughly that order once the waiting stops — because the vast majority of elapsed time in a small back office is not work, it is queue. An enquiry does not take three days to answer; it waits three days and is then answered in twenty minutes.

Remove the queue and the same people, doing the same work, clear an order of magnitude more of it. The judgement-heavy parts do not speed up at all — and should not.

01 · The ledger

A promise becomes a row in the same breath it is made

The commonest way work dies is that somebody says I'll chase that next week and nothing anywhere records it. So every commitment becomes a row with an owner and a due date at the moment it is made — not at the end of the day, not when someone tidies up. A promise with no row is treated as a promise that was never made.

The ledger
02 · The heartbeat

Something sweeps it, whether or not anyone is at a desk

A list nobody reads is a list that does not exist. A scheduled sweep runs through the open rows, acts the ones that are due, and picks up anything a stopped session left behind. Closing a laptop no longer kills the threads that were open on it.

The heartbeat
03 · The coordinator

Two desks never work the same thread

The most expensive failure in a distributed office is two people answering the same client on the same day, differently. A single index holds who owns what, what was last said, and what standing instruction outranks the general rule. It is consulted before anything is sent — not reviewed afterwards.

The coordinator
04 · The controller

Nothing is believed because it said so

Every failure worth remembering reported success while failing. So verification happens at the far end — the actual inbox, the actual live page, the actual carrier record — by a desk with no stake in the answer. Pass, fail, or unverifiable. Unverifiable reopens the job; it is never quietly rounded up to a pass.

The controller
The standard we hold ourselves to

Five questions we have to keep answering yes to

These are not marketing claims. They are the gates a piece of our own work has to pass before we will describe it as finished.

  1. Reversible

    Any change can be undone, and there is a record of what changed and when.

  2. Provable

    The system can demonstrate its own correctness, not merely report it.

  3. Portable

    It does not depend on one machine, one login, or one person being awake.

  4. Observable

    A failure can be traced end to end, from instruction to outcome.

  5. Transferable

    Somebody else can operate it, because the rules are written down.

Automation that has never failed has never been looked at closely.

Ask us what has gone wrong. It is a more useful conversation than a demonstration, and we will answer it.

Start a conversation Read the method