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 is right 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, the current status of any item takes a sort and a scroll to find, and two people disagree about which row is the latest.

Keep one row per physical item, carrying its current state: last tested, next due, who has 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 come off. An item identified only by its tag becomes an unknown tool the moment the tag is missing, which is 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 you can look up, and the missing tag is a fact about the tool 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 that the due date reaches somebody without being looked for.

In Diract you list your own testers, tools and vehicles with who has each, when each is next due for calibration or a service, and what is out of service. The next due date is a field on the item, so a view of what falls due this month is 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 is a site to quote differently, and a lead that fails at six months is a purchasing decision rather than a maintenance one.

Tie an item to the job it was on

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. If a tester turns out to have been out of calibration, you need every job it touched since the last good calibration, and that list either exists or it does not.

What to do first

• Keep one row per item, holding its current state, with the test history behind it
• Mark each item with a code on its body that matches the register
• Put the next due date on the item and filter by it monthly
• Track the tester's own calibration date first, before anything it tests
• Record failures as well as passes, and look at them once a year
• Link items to the jobs they went out on