How to make tool borrow and return records accountable to a person: the tool crib RFID workstation approach

The only record of a tool loan that survives contact with a real workshop is one made at the moment the tool changes hands, by the person taking it, in less time than it takes to walk away. Every other method fails in the same place. The sign-out sheet is honest on Monday and blank by Thursday. The shared spreadsheet is on a computer nobody stands next to. The software with a login for every employee is used by the two people who set it up. None of these fail because people are careless. They fail because they ask for a record at a different time and place from the one where the tool actually leaves.

This article describes how a tool crib records who has what when the record is made at the counter itself, with a badge or a PIN and a reader, and what that record can and cannot tell you afterwards. It is written around TRAKON Asset Basic, because that is the software we build and the one we can describe accurately. The workflow itself is not exotic. If your crib works differently, the questions at the end still apply.

What "who" has to mean at the counter

A loan record is only as good as the identity on it. A shared login gives you the identity of the login, not the person. A name typed into a box gives you whatever was typed. What you want is a person proving who they are in one motion, without a keyboard.

In Asset Basic the tool crib runs a full-screen Workstation that opens on a welcome screen and waits. Someone walks up and identifies themselves in one of two ways: they put their RFID employee badge on the desktop reader, or they type a short PIN. Both come from their user record, which an administrator sets up once. There is no account to create at the station and no portal to sign in to. The people who borrow tools never see the rest of the software at all, and that is deliberate. A fitter on second shift should not need to know the system exists beyond the counter.

Every transaction that follows is tied to that person. That is the whole point of the sign-in step, and it is why the station will not proceed without one.

The transaction takes three moves

Once signed in, the person picks a direction. Exit means a borrow, tools going out. Entry means a return, tools coming in. They then add the tools, and there are two ways to do it.

The first is to put the tagged tools on the reader. The desktop reader we ship for this is the AZD-R1, a flat USB reader with a short read range, which is exactly what you want at a counter: it reads what is placed on it and nothing on the shelf behind. Tools stream into the list as they are read. A beep can be switched on so people can hear each one land.

The second is to type a name or code and pick the tool from a list. This exists for the days a tag is damaged, or for a tool that has not been tagged yet, and it needs no reader at all.

Then one confirmation. Confirm Checkout on the way out, Confirm Return on the way in. The screen shows the count, offers a printed receipt, and returns to the welcome screen by itself. The reset delay is a setting, sixty seconds by default, so an abandoned screen does not sit there signed in as the last person.

That is the whole loan. Badge, direction, tools on the reader, confirm. It is short enough that people do it, and the record is complete because nothing in it was typed.

When the person at the counter is not the borrower

Tools come back in other people's hands. A colleague clears a bench at the end of a shift, or a supervisor collects everything from a job that finished early. If the station forces the return to be logged under the returner, the history says the wrong person had the tool.

The workstation has a Return on Behalf step for this. In return mode, the person at the counter searches for the original borrower, picks them, and confirms. The tool is returned under the borrower's name, and the transaction log records both facts: who had it, and who brought it back. That second fact matters more often than you would think, usually when something is found damaged a week later.

Overdue is a rule you set, not a feeling

A tool that has been out for a long time is only a problem if someone notices. The trouble with noticing is that it depends on who walks past the empty hook.

Asset Basic makes it a number. In the alert rules you set how many days a borrow can run before it counts as overdue, seven by default, and after how many days it escalates to critical, thirty by default. From then on the system does the noticing. The Live Board is one screen of everything currently out: code, tool, category, holder, how long it has been out, whether it is overdue, and its calibration state. It is meant to be left on a wall display by the crib, and it updates the instant a tool is borrowed or returned. Email alerts to a supervisor can be switched on for the events you care about.

The point is not that overdue tools get chased harder. It is that the crib no longer depends on memory to know which ones are overdue at all.

Damage, loss and the tools that should not go out

Two things go wrong with tools that a loan record on its own does not catch: they come back broken, and they get issued when they should not.

For the first, the return screen has a Report Damage step. The returner picks the tool, describes what is wrong and sets a severity, minor, major or critical. The tool's status changes to Damaged and it is flagged, so the next person who tries to borrow it sees a warning at the counter rather than discovering the problem on the job.

For the second, the station checks every transaction against the tool's record at the moment it happens. Borrowing a tool marked damaged or lost, borrowing an instrument whose calibration has expired, returning something that was never checked out, or scanning a tag that is not registered to anything, all of these show up as an alert on that transaction. The calibration case is worth its own article, and we wrote one: calibration due dates checked at the moment of issue. By default an expired instrument is blocked from checkout entirely. What happens on an expired instrument is one of the alert rules an administrator sets, so the policy is yours, but the check itself always runs at the counter.

An unregistered tag deserves a note. If someone puts a tool on the reader and its tag is not in the system, the station offers to register it on the spot, with the tag number already filled in. That is convenient during the first weeks of a rollout and a liability once the register is settled, because it lets anyone add anything. It can be turned off in settings, and we suggest doing so once your tools are all in.

What the history is for

Every borrow and return is logged with time, tool, person, direction, who it was returned on behalf of, and any alert raised at the time. The log can be filtered by date, type or search and exported.

The useful reports are the plain ones. User Activity shows who borrows what and how often, which settles a surprising number of arguments. Asset Utilization shows which tools are out constantly and which have not moved in months, which is the honest input to the question of whether to buy a second one or retire the first. Neither report needs anyone to fill anything in. They are read straight from the transactions the counter already recorded.

What the station cannot tell you

A loan record made at the counter is precise about one thing: who signed for the tool, and when. Here is what it is not.

It does not know who is physically carrying the tool. A badge is not the person. If people hand tools to each other after the counter, the record says the first name. This is a cultural problem, and the only fix we know is to make the counter quicker than the handover, which is what the three-move transaction is for.

It does not know where the tool is now. The last transaction says it went out with a holder. It does not say which bench, which vehicle or which site. If you need to find a tool on the floor rather than know who took it, that is a different problem with a different reader, and we have written about what RFID can and cannot say about location.

It does not inspect anything. A tool comes back and is marked returned. Unless someone chooses to report damage, the record says it came back fine. There is no camera and no judgement, only what the returner reports.

It needs the tool on the reader. The desktop reader reads at close range by design. A tool that walks past the counter in a bag is not read, and the station is not a gate. If tools leaving without a record is your actual problem, that is what exit protection is for, and it uses a different reader mounted over the door.

It needs a tag that reads on the tool. Steel tools need on-metal tags, and the tag has to be tested on the actual tool before you order a box of them. We wrote about why tags fail on metal and how to find out on your own tools.

And it needs a small Windows PC at the counter to run the Bridge that talks to the reader. One Bridge drives one reader. The software itself has a free tier with a ceiling on assets and users, stated on the product page, and above that ceiling you will be talking to us about a plan.

If you are starting from a sign-out sheet

Do not tag everything. Tag the tools that go out most and the instruments that carry a calibration date, because those are the loans where the record earns its keep. Leave consumables alone, and leave the drawer of spares for later. Set the overdue thresholds to what your site actually tolerates rather than the defaults, switch off on-spot registration once the register is complete, and put the Live Board where the supervisor already looks.

Then measure the only thing that matters: whether the people who take tools are using the counter. If they are, the record is complete. If they are not, the software is not the problem, and no software will be.