A process you can't see is a process you can't trust

Every organisation has work that comes back. A report every morning, a check every week, a close every month. It usually isn't written down anywhere. It sits in someone's calendar, in a script that runs at six o'clock, or in the head of the colleague who knows it happens. As long as all goes well, nobody notices. Only when it doesn't happen once does it turn out there was a process.

This piece is about a simple habit that changes that: a recurring process is a ticket that visibly waits until it's its turn.

The hidden process

Take an agent that checks something every morning. You schedule it for a time and then you don't think about it any more. That is exactly the problem. A process that runs in the background has no owner you can point to, no place where you can see when it last ran, and no place where you can see what happened last time. If it breaks, you notice days later.

That is a hidden process. It works until it doesn't, and then nobody knows where to look.

A ticket that is never done

The alternative is almost boring. For the recurring work you create a ticket with a rhythm: every day at eight, every Monday at nine, every hour. The ticket is never closed. When the person doing it has finished, the ticket doesn't go to done, but back to waiting, with the time of the next round attached. At that moment it returns to the pile of work by itself, and someone picks it up.

What you get from this is visibility without extra effort:

• You see that the process exists. It's simply in the list of work.
• You see when it's next. It waits with a date, not with a vague "sometime".
• You see what the last rounds produced. The ticket's log holds the outcomes of the last few times; older ones are shortened to a single line.
• You can stop it. Remove the rhythm or set the ticket to dropped, and the process is gone. One action in one place.

Why this is calmer

An agent doing recurring work starts every round without a memory of the previous one. The ticket is that memory. The previous round is in it, with what was found and done. The next round starts there.

It also makes oversight lighter. You don't have to ask "is that still running?". You look at the list of waiting work and see that it's in there, with tomorrow's date. If it's no longer there, or the date is in the past, you know something is wrong, without having to look inside a script.

A set-up like this also avoids the double location. The rhythm lives in one place, namely in the ticket. A time in a script and a time in a calendar drift apart sooner or later, and then one does what the other already did.

An ordinary week as an example

Suppose a small organisation has five recurring things. Every morning, new requests are sorted. Every Monday, the list of open invoices is checked. On the first of every month, the close is prepared. Every Friday, an overview is sent to the owner. And every night, a copy of the data is made.

If those five live in someone's head or in loose scripts, there is no overview. If the nightly copy fails for a week, nobody sees it until something is lost. If they're waiting tickets in the same list as the ordinary work, the owner's question is answered at a glance: this happens today, this tomorrow, and this was the outcome of last time. If he sees no outcome for the nightly copy for a week, he knows where to start.

Who is the owner?

Every recurring ticket has an owner, and that is a role, not a file. That role picks it up when it's its turn, writes in the ticket what it did, and sets it back to waiting. The checker doesn't look at whether the process runs, but at whether the outcome is right. So a recurring process is treated like any other work: it has someone doing it, a checker and a log.

That may seem cumbersome for work that should do itself. But the work that seems to do itself is exactly the work where oversight disappears first.

What it is not

It isn't a scheduler that solves everything. The fixed time determines when the work is next, not whether it's done well. A round can still fail. The difference is that a failed round leaves a trace in the ticket, and that the ticket simply appears again at its time in the next round.

And it's no reason to give everything a fixed rhythm. One-off work should be an ordinary ticket that is closed. Only what truly recurs gets a rhythm.

Where it becomes visible for me

For me the recurring work sits in the same list as all the other work. A round that is waiting counts among what is scheduled, with its date. At the moment it's its turn, it goes into the pile of work and the right role picks it up. I don't need a separate screen for it. What I want to know is what happens tomorrow, and I see that there.

It feels like a small change, but it removes a kind of uncertainty you only notice once it's gone: the question whether something is running that I'm not thinking about.

What you can do tomorrow

You don't need a system of agents for this. Take a list and do three things:

1. Write down which work comes back at your place without anyone requesting it. Think of reports, checks, closes, clean-ups, reminders. The list is usually longer than you expect.
2. For each item, put in one place who does it and when it's next. One place, not two.
3. Every week, check whether each item on the list really happened last time, and what it produced. Recurring work without a trace of the last time is a hidden process.

You'll almost certainly find a process that has been running for months without anyone knowing who does it. That is nobody's fault. It's what happens to work that is written down nowhere.

What quietly keeps something running at your place that nobody looks at, and what would happen if it didn't happen for a week?

#AIAgents #Workflows #Automation

All pieces