A test and tag register you can actually search

Every tested tool carries a tag saying who tested it and when it is next due. That tag does its job perfectly for one person, standing in front of one tool.

It answers none of the questions you have at the desk, which are about the fleet. What falls due next month, what has failed twice, and where a given item sits now.

The register answers different questions from the tag

A register earns its place the moment it can answer these without a walk around the yard.

• What is due in the next thirty days, so testing is a planned afternoon rather than a scramble before an audit.
• What is out of service, and whether anybody has taken it back into the field anyway.
• What has failed before, because a lead that fails twice is a lead to retire rather than repair.
• Who holds each item, which matters most on the day a customer asks what you used on their site.

One row per item, not one row per test

The common mistake is a spreadsheet where each test is a row. It grows forever, and any item's current status takes a sort and a scroll. Two people then disagree about which row is the latest.

One row per physical item carries its current state. Last tested, next due, who holds it, in or out of service. The test history hangs off that row rather than competing with it.

Give each item an identifier that survives the tag

Tags do not survive a year on site. An item identified only by its tag becomes an unknown tool the moment that tag disappears. Usually the same day it took a knock.

Mark the item itself, on the body, with a short code that matches the register. Then a tool with no tag is still a tool the register can identify. The missing tag becomes a fact about it rather than the end of the trail.

Make the due date do the work

A register nobody reads is a list. What makes it useful is a due date that reaches somebody unprompted.

In Diract you list your own testers, tools and vehicles. Each one shows who holds it, when calibration or a service falls due, and what is out of service. The next due date is a field on the item. What falls due this month is then a filter rather than a job somebody does by hand.

That also covers the tester itself. A tester out of calibration invalidates every test it performed since, which is the one failure in this whole area that is genuinely expensive.

Record the failures, not only the passes

Most registers only note a pass, because a failed item goes in the bin and feels finished. The failure is the useful record: it tells you which brand of lead fails, which site destroys equipment, and which person is hardest on tools.

None of that is an accusation. A site that eats extension leads deserves a different quote. A lead that fails at six months is a purchasing decision rather than a maintenance one.

Tying an item to its job

When a customer asks what you used at their property, the answer should take a minute. That means the job knows which items were on it, which is a link rather than a memory.

The same link answers the harder version of the question. A tester found out of calibration means you need every job it touched since the last good reading. That list either exists or it does not.

What to do first

• One row per item holds its current state, with the test history behind it
• Mark each item with a code on its body that matches the register
• The next due date sits on the item, and a monthly filter reads it
• The tester's own calibration date comes first, ahead of anything it tests
• Failures record alongside passes, and get a read once a year
• Each item links to the jobs it has visited