Asset management in TOPdesk: control without logging it all

Reading time about 7 minutes

Asset management is the part of TOPdesk most organisations once started enthusiastically and where the records now lag furthest behind reality. That is not laziness. It is almost always a matter of wanting to record too much and maintaining too little.

An asset register that is eighty per cent correct is worse than no register at all. With no register you know you have to go and find out. At eighty per cent you think you already know.

Start with the question, not with the equipment

The usual start is an inventory: everything we own goes in. That produces an impressive list and, a year later, a list nobody trusts.

The reverse order works better. Which questions do you want to answer without ringing round?

Who uses this device, and where is it?
Which laptops come out of warranty this year?
Which systems does this outage touch, and who should I tell?
What do we have in stock, and what should we order for next month's intake?
Which licences are we paying for people who have left?

Each of those questions determines which fields you need. Anything that serves none of them, you leave out — not because it is uninteresting, but because every field you record also has to be maintained.

Record as little as possible by hand

How long an asset register stays useful depends almost entirely on how much of it arrives automatically. Manually entered data ages; linked data does not.

In practice these are the sources that return the most:

Entra ID or Active Directory for people, departments and joining and leaving dates.
Your MDM or endpoint management (Intune, Jamf) for hardware actually in use, including operating system and last check-in.
Purchasing records for purchase date, supplier and warranty term — details you need later and cannot reconstruct after the fact.

Whatever you link, you then stop editing by hand. A field that can come from two sources is a field that will start to disagree with itself.

The difference between assets and a CMDB

These two are often used interchangeably, which produces registers that serve neither purpose. An asset register is about ownership: what do we have, whose is it, what did it cost, when do we replace it. A CMDB is about dependency: which components need each other to deliver a service.

You do not always need both. A CMDB only pays for itself once you use it during incidents and changes — to see what an intervention affects. If you do not use it for that, you are maintaining a model nobody consults. Start with assets alone.

The lifecycle is where it goes wrong

New devices usually get entered properly. The problem is at the other end: devices handed back, moved to another user, left in a cupboard or disposed of. Those are precisely the moments when nobody thinks about TOPdesk.

The answer is not to insist more firmly that it must be done, but to tie the record to a moment that happens anyway:

A leaver in the HR system automatically creates a task to collect equipment.
A ticket saying "laptop broken" changes that device's status, instead of someone having to do it separately afterwards.
A replacement round runs as a change, so old and new are updated in one action.

The principle: if maintaining the record is a separate action, it will not happen. If it is part of an action that already exists, it will.

Check that it is true

A register that is never held up against reality slowly loses its value without anyone noticing. Two simple checks catch most of the drift:

Devices the register says are in use, but which have not checked in with your endpoint management for months. Those have been replaced, lost, or are in a drawer.
People holding equipment who are no longer in the HR system. This is also your fastest route to saving on licences.

Put those two lists on your dashboard rather than in a quarterly report. Drift you see the same week is a correction; drift you see after three months is an investigation.

In closing

Asset management rarely produces a dramatic saving on any single day. What it produces is the ability to answer questions without ringing round, replacement you can plan for, and knowing who to warn during an outage. That is enough — provided the data is right, which is why the scope of the register matters more than its completeness.