Why Spreadsheets Fail for Campus Key Management

Almost every facilities team I talk to starts out the same way. There is a spreadsheet. It lives on a shared drive, or maybe in someone's email if the org is small enough. It has columns for the key number, the room or door it opens, the staff member who holds it, and the date it was issued. There may or may not be a return date.

It works. For a while.

Then it stops working, and nobody can quite point to the day it broke. They just know that when somebody walks into the office and asks "who has the master for the science wing right now," nobody can answer with any confidence. The spreadsheet says one thing. The drawer says another. The person who would actually know is on vacation.

I have had this conversation with directors at school districts, community colleges, healthcare campuses, and one very large government installation. The story is identical every time. So before we talk about what to do about it, let's talk about why it happens.

The four ways a key spreadsheet quietly falls apart

1. It does not keep an honest history

A spreadsheet captures the current state of the world. When Maria checks out key K-0042 in March, you update the row. When Maria returns the key and James takes it in June, you overwrite the row. Now there is no record that Maria ever had the key.

That is fine until something goes wrong — a break-in, a lost key, an HR investigation, an audit. Then you need to answer "who had this key between March and June," and the spreadsheet cannot tell you. The honest answer is "I do not know," and that is not an answer anyone wants to give in front of a board or an insurance adjuster.

2. Anyone with the file can edit anything

Permissions on a shared spreadsheet are blunt. Either you can edit the whole file or you cannot. There is no way to say "the security supervisor can change this row but not that row." There is no way to say "nobody can delete a row without leaving a trace."

So when a key disappears and the responsible party knows about it before the audit, that row can quietly become "returned 2024-09-12, condition: good." The spreadsheet does not remember being changed. Neither does the person who changed it, by the time anyone asks.

3. It does not chase anyone for you

When a key goes overdue, the spreadsheet will sit there indefinitely. It will not email the holder. It will not flag the row red until someone manually applies a conditional format that nobody else maintains. It will not surface "the seven oldest checkouts on campus, by holder" without an analyst-grade pivot table.

In practice, this means overdue keys go unrecovered. Not because anyone forgot on purpose, but because chasing them is a manual project on top of the actual work of running facilities. The team has bigger fires.

4. It does not survive a personnel change

Almost every spreadsheet I have seen was built by one person. That person knows what every column means, what the abbreviations stand for, and which rows are reliable versus which are stale. When they leave — promoted, retired, or moved to another district — that institutional knowledge walks out with them.

The replacement opens the file, decides it is incomprehensible, and starts a new one. The old keys do not migrate. The history is lost. Six months later there is a new mystery key in a drawer with no record of where it came from.

What a real key management system has to do

When we built KeyDog, we started from the failure modes above and worked backwards. A purpose-built system for physical key management on a campus is not a spreadsheet with a prettier face. It has to do four things the spreadsheet cannot.

It has to keep an immutable history. Every issuance, return, change of status, and change of holder is a separate event. The current state is just a projection from the event log. When you ask "who held this key in March," the answer is not somebody's memory — it is the record.

It has to enforce role-based access. The administrative assistant can issue and return keys. The facilities director can grant fob profiles. The security supervisor can run reports. Nobody can rewrite history.

It has to chase overdue keys automatically. Configurable schedules. Email reminders to the holder. Escalation to the supervisor after a grace period. A daily report of everything still out, in priority order.

It has to outlive the person who set it up. The records have to be self-describing — full names instead of cryptic codes, attached agreements instead of "see the binder on Janet's desk," and a structure that any new admin can read without a half-day training session.

What this looks like in practice

When a facilities team moves from a spreadsheet to KeyDog, the first thing they usually notice is not the software. It is the conversations that stop happening. The shoulder-tap from the principal asking who has the auditorium master. The unanswered email from the auditor asking for three years of issuance records. The Monday-morning hunt for a key that nobody remembers handing out.

Those conversations do not stop because the keys get less important. They stop because the answer is now somewhere everybody can find in fifteen seconds. The team's attention can go back to the work that actually requires a human being.

If your spreadsheet is still working today, that is genuinely fine. The question is whether it is going to be working two years from now, after the next reorg, the next audit, or the next time a master key takes a walk.

When you decide it is not, we are happy to show you what a real system looks like.