Filed as chatter
A document was waiting on one person's signature, and the request reached them as a line in a digest. Not a training gap. A row in a routing table.
A document was sent for signature. It sat there. The person who had to sign it did not know they had to sign it.
They were not ignoring it, and they had not missed a message. The message had arrived exactly as the system intended, and the way the system intended was wrong.
What the machine actually did#
The signature request went out carrying a generic type: question. Types are mapped onto rows in a grid, and question had been mapped, sensibly enough, onto the row for comments. The comment row's default delivery is a bulletin: held back until the next scheduled broadcast, three a day, ringing nothing, arriving as one line among a dozen others that also did not need doing right now.
So a document that was holding up a payment was delivered as chatter.
Every component in that chain did its job. The request was raised correctly. It was classified into a real category. That category was routed by a rule somebody had written down on purpose. Nothing failed. The design had simply never been asked what a signature request is, so it answered a different question and answered it well.
The distinction we ended up writing down#
The instinct, when this surfaces, is to reach for importance: mark it urgent, give it a red badge, put it higher in the list. That is the wrong axis, because everybody's own work is important and a scale where everything is at the top is not a scale.
The useful question is not how important a message is. It is what it asks the reader to do. There are only three answers.
- Nothing. You should know this happened. Read it whenever.
- Later. Look at this next time you are looking at things.
- Now. Somebody is standing still until you act.
A signature request is always the third. It is not information about work; it is a request for a specific person's hand, and until that hand moves, a document, a payment and usually another human being are all stopped. It now has its own type, sitting on the row for things awaiting approval, and it says plainly that it asks for an act. It arrives on its own and it rings. It also says which page of the document the signature goes on, because "sign this" without "here" is still a small piece of homework.
Why nobody reported it#
This is the part that makes it our kind of problem.
The person who had to sign did not know there was anything to report. From where they stood, nothing had happened. The person who sent it assumed it had landed, because sending it had produced no error and the software said it had gone. Both of them held a completely consistent picture of the day, and the two pictures did not overlap at the point where the work was stuck.
That is the most durable kind of gap. It has no owner, because nobody experiences it as a gap. It gets discovered the way this one did: somebody asks why a thing has not moved, and the answer turns out to be that nobody was ever told to move it.
Defaults are decisions#
Every routing table has a default, and a default is a decision made once, in the abstract, by somebody who was not thinking about your document. It then applies to every message that will ever be classified into that row, for years, without being revisited, because nothing about it ever looks like a choice again. It looks like the way things are.
That is why the fix was not to make the alert louder. Loudness is a resource with a fixed supply. An application that rings for everything is an application people mute, and a muted application delivers nothing at all. Quiet is a feature, and the bulletin row is doing real work for the messages that genuinely belong to it.
The fix was to stop lying about what the message wanted. Once a request says "this asks somebody to act", the routing follows on its own and no one has to argue about priority.
The general shape#
If something in your work regularly waits on a person who did not know they were being waited on, the problem is unlikely to be that person. Look at how the request was categorised on its way to them, and ask what else shares that category. You will usually find one bucket carrying two kinds of message: the kind that is nice to know, and the kind that is holding up a room. They cannot share a delivery rule, however tidy it looks in the table.
The general form of the routing rule is set out in an alert that rings for everything, and the wider habit of never revisiting a setting made once is a default is a decision somebody made once.
Everything else in this class is the same. We wrote about the gap you stopped noticing before we had this example. This is what one looks like from the inside.