How to Use IntrApp Efficiently: Best Practices for Teams

The hard part of rolling out a system is not what you switch on. It is what you leave switched off.

On day one everything looks interesting, so everything goes in: a kanban board, a knowledge base, time tracking, a file manager. The system genuinely works that way. By week three, though, somebody says they cannot find it, because the menu has fourteen entries and their job uses three of them.

Rollout is subtraction, not addition

Turning on as much as possible at once feels like the fastest way to get your money's worth from a new system. In practice it works the other way around.

Somebody who uses three features a day but sees fourteen answers a small question on every login: which one is it now. Once, that is nothing. Thirty times a day, across five people, for three months, that is exactly the low-grade tiredness that ends with nobody opening the thing at all.

So a good rollout starts by taking away. Begin with the work that would happen next week anyway, and hide everything else until somebody asks for it.

Take away what is not theirs

On the administration side, menu entries are controlled per role. If someone has no business with the contracts folder, they should not see the contracts folder.

The point is not permissions. It is the surface. A warehouse colleague who sees four menu entries learns the system in two days. The same colleague looking at fourteen spends three weeks asking questions, and the whole time suspects there is something else they were supposed to be doing.

Hiding is reversible. If it turns out they do need it after all, that is one click.

There is a second benefit that only shows up months later. When each person sees only what they work with, the interface itself tells you who to go to about what, and nobody has to learn the responsibility map separately.

Keep the places where the work actually happens

What stays is whatever the day cannot end without, and in most companies that is the same three things: where the work stands, who the customer is, and what was decided.

That is why the kanban board is not a project management exercise. It replaces the Monday morning question. If the board does not reflect where the work stands, it is not a board but scenery, and you are better off without it. What keeps a board alive, and when it turns into a second layer of admin, is a separate article.

The link between a customer and a task works the same way. The value is not the data entry. It is not having to search while somebody is on the phone with you. A comment belongs next to the task because six months from now you will not want to know who wrote what. You will want to know why you decided the way you did.

Without an agreement, the settings are worth nothing

The most common failure is not in the software. It is that nobody said out loud when something goes into it.

Three sentences are enough, and none of them needs to be a policy. Work that has started goes on the board. Work that is stuck gets written there instead of mentioned in passing. Anything promised to a customer has a date on it.

The second one is the hard one. Admitting you are stuck is uncomfortable, so the manager has to do it first. Otherwise the board only ever says that everything is fine, and nobody believes it.

What is written down does not have to be explained twice

Almost every company has the sentence: ask Kate, she knows how that works. Kate does know, and because of that Kate stops her own work three times a week.

A knowledge base earns its keep by replacing those three interruptions, not by producing beautiful documentation. Three paragraphs describing a process, with the real example in them, beat a twenty-page manual nobody opens.

The file manager is the same story. Search runs inside the documents too, so a contract turns up even when nobody remembers what it was called. That matters on the day a customer asks and the answer cannot wait until tomorrow.

When to leave all of this alone

If three of you sit in one room and everyone hears what the others say on the phone, visibility is already solved. A board adds nothing there. It only costs you the time of writing down what the others already heard.

If a process happens once a year, do not document it. The description will go stale, and next time believing it will cost more than working it out again.

These settings start to matter when you cross a certain size, when someone works remotely, or when the number of customers stops fitting in anyone's head. We wrote in more detail about the signs that your current way of working has run out.

In six months the job will be clearing up

Whatever starts, accumulates. Half a year after rollout you will have eight boards of which three are live, and fifteen knowledge base articles of which four are out of date.

At that point the most useful thing you can do is delete. A finished board goes to the archive. An outdated article is either updated or removed. This is not a loss. A system stays usable as long as what you see in it is alive.

Deleting is reversible anyway. Most items can be restored from the trash, so you do not have to be brave about it.

The one rule that stays

IntrApp does not become valuable because you turned everything on. It becomes valuable when the things people can see are the things they use. If something has stood empty for three months, it is not missing. Switch it off.

If something genuinely is missing, you can request a feature. If roughly three quarters of our customers would use it too, we build it for free and everyone gets it. The judgement is ours, because we see the whole customer base, and what we promise is not immediate delivery: it is that a widely useful request enters development.

I'll try the demo