The gap between saying and doing
“Can someone chase that supplier?” is not a task. It has no owner and no deadline, and in a group of five it reads as handled by everyone and is handled by nobody. This is the single most common way small teams drop work, and it has nothing to do with effort.
The fix is unglamorous: three fields.
The three fields
- One name. Not a team, not a role. A person. Shared ownership is unowned.
- One date and time. “Today” is not a deadline when the shift ends at six.
- One status. Not started, in progress, done. Three is enough. More is a taxonomy nobody maintains.
That is the whole system. Everything else a project tool offers is optional for a store team of under ten.
Why a separate board usually fails
Not because boards are bad. Because they are a second place. The conversation happens in chat, and then somebody has to remember to go and mirror it onto the board, and that person is busy. Within three weeks the board is a fiction and the team has quietly reverted to chat, now with the added cost of an abandoned tool.
Any system that requires re-typing what was just said will be abandoned by the second busy week.
Keep the task where the conversation is
If a task can be created directly from the message that prompted it, the re-typing step disappears and so does the drift. The context comes with it: whoever picks it up can see what was actually said, not a summarised version of it.
This is the model Store Huddle uses. A message becomes a task in two clicks, the task carries an assignee, a due date and time, a status and a priority, and the card stays in the room where the conversation happened. The task guide has the specifics.
A habit worth building
At the end of each day, one person scans the day's rooms and asks a single question of anything unresolved: does this have a name and a date? If not, give it one or explicitly decide it does not need doing.
Five minutes. It is the highest-leverage five minutes in a store team's day, and it works regardless of which tool you use.
The three fields, and why only three
Task systems fail in small teams by asking for too much. Every extra field is a reason not to create the task, and a task not created is work not tracked.
One name. Not a team, not a channel. The single most important field, because a task assigned to a group is assigned to nobody. This is the same diffusion that makes "can someone check this?" reliably go unanswered in a group of six.
One time. Not a priority label, an actual due time. Priorities are comparative and everything drifts to high; a time makes lateness visible, which is the entire mechanism.
A visible done state. If nobody can tell the difference between finished and forgotten, you have a list rather than a system.
Everything else, including estimates, labels, sub-tasks and dependencies, is optional and mostly unnecessary below about ten people.
Why the trip to another tool kills it
Work is identified in conversation. If capturing it means opening a second application, re-typing the context and assigning it, the step gets done when things are calm and skipped when they are busy.
Busy is exactly when it matters. So the test of a task system is not what it can do, it is how many actions stand between noticing work and it having an owner. If that number is more than one or two, the system will be accurate during quiet weeks and wrong during the weeks that count.
This is also why integrations between a chat tool and a project tool help less than expected. They reduce the typing, not the context switch, and the switch is the expensive part.
The habit that makes it stick
One rule, applied consistently: if it is going to be done by someone other than you, or later than now, it becomes a task.
The common failure is creating tasks only for big things. Big things get remembered anyway. What gets dropped is the small item somebody agreed to in passing, which felt too minor to record and was forgotten within the hour.
For the first fortnight, one person converts things other people said they would do. Slightly annoying, and it establishes the norm faster than asking everyone to change their own behaviour.
Reviewing without turning it into admin
Once a day, look at what is overdue. Not to chase, but to sort: still matters and gets a new time, no longer matters and gets closed, or has been carried three times and needs a decision about whether it is real.
The third category is the useful one. Anything repeatedly deferred is either not important or blocked by something nobody has named, and both need saying out loud rather than another deferral.
Closing dead tasks matters more than it sounds. A list containing items nobody intends to do is a list people stop trusting, and an untrusted list stops being read.
What to do about work that has no owner yet
Sometimes a task genuinely cannot be assigned at the moment it is created: nobody is available, or it is unclear whose area it falls in.
The temptation is to leave it unassigned and sort it out later. In practice unassigned tasks are invisible, because nobody's list includes them and nothing surfaces them.
Assign it to whoever is running the day, with a due time of that afternoon. Their job is not to do it, it is to decide who does. That converts an ownerless item into an owned decision, which is a much smaller and much more reliable thing to ask of somebody.
Tasks that come from alerts
The highest-value case, and the one most easily lost.
An alert reports a fact. A task assigns a response. Without the second step, a low-stock alert is a notification somebody saw and intended to act on, which is not the same as work that will happen.
The practical test is whether turning an alert into an owned task takes one action or several. If it means reading the alert, opening another tool, re-typing what happened and assigning it, the step will be skipped exactly when the store is busy enough for it to matter. Store Huddle creates the task from the alert with the product or order already attached, which is the difference between a habit that holds and one that holds only on quiet days.
When a task is the wrong tool
Not everything should become a task, and over-tasking produces a list nobody trusts.
Recurring daily work belongs in a checklist that resets, not a tracker. Adding "check overnight orders" as a task every morning clutters the list and trains people to skim it, which then applies to the items that actually needed attention.
Work spanning several weeks with real sequencing belongs somewhere that can show sequence. And anything genuinely being done right now by the person saying it does not need recording at all; the overhead exceeds the risk.
The test is the one at the top: someone else, or later. If neither applies, just do it.
Getting the team to actually use it
The habit forms in about two weeks and needs a nudge, because creating a task is a small extra step at a moment when nobody feels they have time.
The move that works is converting other people's commitments for them. When someone says they will do something, turn it into a task with their name on it rather than asking them to. Mildly presumptuous, and it establishes the norm faster than any request, because people see the value before they have to do the work.
Within a fortnight most people start doing it themselves, largely because being on the receiving end of a clear assignment is noticeably better than trying to remember a passing agreement.
Common questions
Do we need a project management tool for store tasks?
Usually not. Most store work is same-day interruptions rather than multi-week projects, and project tools add overhead without addressing that.
What is the minimum a task needs?
One name, one time, and a visible done state. Anything beyond that is optional below roughly ten people and mostly reduces how often tasks get created.
Why do task lists stop being used?
Because creating a task costs more than doing a small job. Once the list stops matching reality, people stop trusting it, and once they stop trusting it they stop updating it.
Should small jobs become tasks?
Yes, and they are the ones that matter. Big items get remembered anyway; the thing someone agreed to in passing is what gets dropped.
How often should tasks be reviewed?
Briefly once a day. Sort overdue items into still relevant, no longer relevant, and repeatedly deferred. The third group needs a decision rather than another date.