Priority is impact, not rank
The hardest question to answer in a small company is not how much you spend. It is where the day went.
Everyone worked. Nobody stopped. And still, at the end of the month, there is no sentence that explains what got done — only the sense that a lot of running happened.
That is not a lack of effort, and it is almost never a lack of people. It is that the work came in through places that keep no record: the message on the phone, the "just one quick thing" in the corridor, the request made at the office door. Each one is small. Together, they are the whole day.
The request that leaves no record
A request written down nowhere has a curious property: as far as the company is concerned, it did not happen.
Nobody knows how many there were, how much time they consumed, or how many times the same problem came back. Whoever handled it knows, and nobody else.
And there is an effect nobody anticipates: whoever is good at handling things becomes the most interrupted. Not because anyone decided it, but because the shortest path to getting something solved is to go and talk to them. The reward for being efficient is being interrupted more often.
A single intake is not bureaucracy
The fix is simpler than it looks, and it fits in one sentence: every request comes in through one place. A helpdesk, an inbox, whatever it is — the tool matters little.
What usually stalls this change is reading it as bureaucracy. It is not:
The real purpose of the discipline: governance over the company's time. The portal is not bureaucracy — it is the instrument that makes visible where IT time is invested, and therefore governable.
Notice what changes: you do not start controlling people. You start seeing where the time went, which is information that simply does not exist in the company today.
The rule that stings at first
Once the queue exists, it forces the question: who comes first?
Golden rule: priority is set by business impact, not by the rank of whoever asks. Anything arriving outside the queue is recorded by whoever handles it — no exceptions.
That is the part that requires a decision from the owner, not from the technical team. Without it, the queue becomes an ornament: it still exists, but whoever shouts loudest — or holds the highest rank — still goes to the front, and the person handling requests ends up in the middle of a dispute that is not theirs.
And it is worth noticing the end of that rule, which is the easier half to forget: what arrives outside the queue is not refused, it is recorded. Nobody has to say no to the owner. They just have to write it down before solving it.
Three types, and why the difference matters
It is worth splitting what comes in three ways, by its relation to what already exists:
A project is something new, that does not exist yet. An incident is something already delivered that broke. A request is an adjustment or improvement to something already delivered.
It looks like textbook classification, and it is the most revealing item on the list. Without it, everything is "demand", and a team that spent the whole month firefighting looks like a busy, productive team. With it, it becomes visible that nobody built anything — and that changes what gets decided next month.
The number that only shows up afterwards
Once requests are recorded and separated, a number appears for free that the owner understands without translation: the ratio between firefighting and building.
How much of the month went into fixing what broke, and how much into building what did not exist yet. It is the most honest health measure a technology operation has, and it asks for no new tool at all — it asks for the requests to exist in writing.
The test
Think about last month, and answer without asking anybody:
How much of your team's time went into firefighting, and how much into building?
If the answer is an estimate, it is not that the operation is in bad shape. It is that it is still invisible — and an invisible operation does not improve on purpose. It improves by luck.