Message, task or document: where each thing belongs

The problem is sorting, not software

Teams that feel disorganised usually have enough tools. What they do not have is agreement about which kind of thing goes where, so the same piece of information ends up in chat on Monday, in a task on Tuesday and in a document on Wednesday, and none of the three is authoritative.

The symptom is familiar. Somebody asks a question that was answered last month and nobody can find the answer, because the answer was a message. Or a procedure exists as a document that is three revisions out of date, because the actual current practice was agreed in a conversation. Or a task board is full of things that are not tasks.

Adding a tool does not fix this. Sorting does, and sorting takes about ten minutes to agree and a few weeks to become habit.

Three questions

For anything you are about to write down, ask these in order. The first one that gives a clear answer decides it.

Question one: will this still be true in three months?

If yes, it is a document. How you process a return, what the packing standard is, which courier to use for which weight, what a new starter needs in week one. These are procedures, and procedures belong somewhere durable with a title, because they will be looked up by somebody who was not in the conversation where they were decided.

If no, it is not a document, and writing it as one is how documents become untrustworthy. A document containing a mixture of permanent policy and last Tuesday's decision teaches people that documents are unreliable, and once they believe that they stop reading all of them.

Question two: does somebody have to do something?

If yes, and it is not already obvious who and by when, it is a task. Chase the supplier about PO 4471. Photograph the damaged pallet before the courier collects. Update the shipping cutoff on the theme.

The test is not importance. It is whether there is a specific action with a specific owner. "We should really tighten up returns" is not a task, it is a topic. It becomes a task when it turns into "write the returns rule by Friday, Sofia".

Tasks put in chat are the single most common failure in small teams. A message asking somebody to do something has no owner until they reply, no due date, and no state. It looks like it was handled because it was read.

Question three: is anything else true?

Then it is a message. Most things are messages, and that is correct. "The pallet arrived", "customer on the phone about 1042", "I am taking lunch now". Ephemeral, contextual, and they should be allowed to scroll away.

The mistake is not that teams send too many messages. It is that they send messages containing the other two types and expect the message to hold them.

The awkward cases

A decision made in conversation that changes how you work

This is the most common thing to get wrong. Somebody proposes a better way to handle backorders, three people agree in chat, and everybody starts doing it. It is now policy and it lives in a thread.

The handling is a two-step: have the conversation wherever conversations happen, then have whoever proposed it write the outcome into the document. The conversation is a message. The conclusion is a document. Skipping the second step is how a team ends up with practices nobody can explain the origin of.

A recurring task

Stock count every Monday, supplier check-in on the first of the month. The instance is a task. The procedure for doing it is a document. Keeping both means the Monday task can say "do the stock count" rather than restating how, and the how stays correct in one place.

Something urgent that is also policy

A courier suspends a service and you need a different one today, and also from now on. Message it so people act now, task the person who needs to switch it, and document the new default. All three, in that order. Urgency does not exempt something from being written down, it just changes what comes first.

How to introduce this without a process document about process

Do not announce a taxonomy. Instead, for two weeks, when something lands in the wrong place, move it and say why in one line. "Putting this in the returns doc so it is findable." "Making this a task so it has an owner."

That is enough. People copy what they see more readily than what they are told, and a rule demonstrated eight times becomes habit faster than a rule circulated once.

The one thing worth saying explicitly is the tasks-in-chat rule, because it is the costliest and the least obvious. Something like: if you are asking a specific person to do a specific thing, it needs an owner and a date, not a message.

What good looks like after a month

• Somebody can find how a return is processed without asking anyone.
• Nothing is waiting on a person who does not know it is waiting on them.
• The documents are short, because only durable things are in them.
• Chat is busy and nobody minds, because nothing important depends on someone having scrolled back.

One week, sorted

Abstract rules are easy to agree with and hard to apply, so here is a realistic week of things a small store team says, run through the three questions.

• "The DHL pickup is at 3 today, not 4." Not true in three months. Nobody needs to do anything beyond knowing it. Message.
• "We should stop offering next-day on the heavy items." A topic, not yet a task. It becomes one when somebody owns it: message now, task once decided, document once changed.
• "Can someone chase the pallet that was due Tuesday?" Specific action, unnamed owner. This is the classic chat-task and the most common thing to lose. Task, with a name and a date.
• "Fragile items get double-boxed, always." True in three months. Document, in the packing standard.
• "Customer on 1042 is upset, I am handling it." Ephemeral, already owned, no lookup value later. Message.
• "We agreed refunds under 30 do not need approval." A decision that changes how people work. Discussed in chat, but it is now policy. Document, and say in the chat that you have put it there.
• "Stock count Monday." Recurring. The Monday instance is a task; how to do a count is a document.

The pattern that emerges is the useful part: most of what a team says is correctly a message, a small number of things need an owner, and a very small number are permanent. Teams that feel disorganised have usually got the last two categories sitting in the first.

The failure mode of each container

Each of the three goes wrong in its own way, and recognising the symptom tells you which boundary is leaking.

• Documents rot. Symptom: somebody says "that doc is out of date" and everyone agrees. Cause: non-durable things were put in them. Fix: only the three-month test goes in.
• Task lists bloat. Symptom: a board nobody opens, full of items with no dates. Cause: topics were filed as tasks. Fix: if it has no owner and no date, it is not a task yet.
• Chat swallows things. Symptom: "I thought you were doing that". Cause: a task was sent as a message. Fix: the tasks-in-chat rule, enforced gently and repeatedly.

Related reading: turning messages into tasks covers the mechanics of the second question, and the SOP template covers writing the durable version so people actually open it.

Common questions