Track the serial, not the laptop

Why the description is not enough

Descriptions collide. Buy five of the same model and the list holds five rows that read the same. They differ only by who has them, and that is the field most likely to be out of date.

Descriptions also drift. A machine gets more memory, a new screen, a new keyboard. The row now describes a laptop that no longer exists.

Then a dispute arrives. Somebody hands back a laptop and the list cannot say whether it is the one they were given. Nobody can prove much, so everybody agrees to move on.

Three fields that settle it

An internal code gives each machine one name of its own. It survives every repair and every handover.

A serial number ties that code to a physical object the maker also names. Match the two at handover and again at return. Five seconds, and the whole class of argument disappears.

A verified state records whether anyone has actually checked. That is the honest part. Most lists quietly assume they are right, and a verified flag admits the gap between a record and a look.

• Device code: internal, stable, survives repairs.
• Serial number: ties the code to the physical object.
• Verified flag: has anyone actually checked?
• Status: ready, under maintenance, or retired.
• Health and assignment, with who holds it now.

What the register is for beyond recovery

The specifications are filterable. Chip generation, memory, screen size, storage. So a machine gets matched to a role, rather than handed out to whoever asks loudest.

The counts answer a buying question. How many are ready. How many are being repaired. How many retired, and how many are free right now.

A device usage figure sits beside those. That is the number that stops a team buying hardware it already owns.

Where the register earns its keep

Three moments, and they are the moments a sheet always fails.

At handover. The serial goes on the form the person signs, so both sides hold the same fact. A handover with no serial is the root cause of most later gaps.

At a return. The machine coming back is matched against the machine that went out. One check, done in front of the person, before they leave.

And at an audit. Starting from the rows nobody has verified turns a full count into a short list, which is the difference between an audit that happens and one that gets postponed.

None of that needs clever software. It needs one stable code, one serial, and a habit.

Starting a list that is actually true

Most teams already have a sheet, and the temptation is to import it. Resist that.

An imported sheet arrives with every wrong row intact, and now those rows look official. Better to start from the machines and build the list from what you can hold.

Walk the desks once. Record a code, a serial, a model, and who has it. Mark each one verified as you go, with the date.

Anything on the old sheet that you could not find goes on a separate list, as a question rather than a row. That list is short and useful. A single list with unfindable machines buried in it is neither.

A day of this is usually enough for a team of thirty, and it produces something you can trust for years if the handover habit holds.

Why this matters more than it sounds

Hardware tracking is the least interesting thing on any HR shortlist, and it is where a surprising amount of friction actually lives.

A joiner with no machine on day one. A leaver whose laptop nobody can place. A team buying three machines because nobody could see the four sitting in a cupboard.

Each is small on its own. Together they are several days a year of somebody's time, and one of them is the first impression a new person forms of how the company runs.

The fix is not a better tool. It is one stable identifier used consistently, at handover and at return, by people who were told why it matters.

Cheap to start, cheap to keep, and it quietly removes a category of argument that most teams have simply accepted.