A facilities manager requests another restricted key, but the customer record only names them as a recipient. Stop. A locksmith key control register must show who can approve the key before you cut or release it.
It must also show who holds each key now and how it got there. One editable holder field will not do that. Record authority, custody events and unresolved problems separately.
Set the client and site scope before recording keys
Start with the legal customer and the property. People move roles. Managing agents change. Keep the site ID stable, but give each customer-to-site relationship effective dates. When ownership, tenancy or management authority changes, close the old relationship and create a new one rather than attaching a new legal customer to the old authority chain.
Record the customer name, trading name if used, site address, state or territory, postcode and the customer’s nominated contacts. Give every property a stable site ID. For a multi-site customer, create one site record for each address.
Do not treat the whole customer portfolio as one site. Approval for a warehouse in one state does not automatically cover an office in another. The key system, customer contacts and licensing checks may differ.
For commercial locksmith clients, write down which systems the register covers. That could include a restricted system, master key system, service keys, plant-room keys, emergency sets or keys held in a controlled cabinet. Leave unrelated tenant keys outside the register unless the customer has asked you to control them.
Before accepting work at a new location, use the Australian Business Licence and Information Service (opens in a new tab) to identify the state or territory licensing regulator. Ask that regulator which licence or registration covers the locksmith activity and location, then record the answer for the job.
Name one person in your business as the register owner. That person controls changes, resolves duplicate records and decides who may view protected opening details. Field locksmiths still add custody events. They do not keep separate private lists.
Keep a correction history for site, key asset and authority records. For every correction, record who changed it, when they changed it, the reason, the source and the superseded value. Never silently replace a customer name, site reference, key identifier or authority period.
The register contains names, contact details and protected access information. Check the current requirements that apply to your business with the Office of the Australian Information Commissioner (opens in a new tab) and any state or territory privacy body that covers your business or customer. Write down who may access the records, how long you keep them, how you dispose of them and what your team does after a privacy or security incident.
Separate requesting, approving and receiving a key
Permission and possession are different.
A building manager may request a key. A facilities manager may approve it. A contractor may receive it. The security desk may accept its return. Record each action against the person or role allowed to perform it.
Build an authority matrix with these fields:
| Authority field | What to record |
|---|---|
| Customer and site | The account and property covered |
| Person and role | The customer’s nominated contact and job role |
| Permitted action | Request, approve, receive or return |
| Approval rule | Which actions require approval and when approval must be recorded |
| Prohibited role combinations | Actions the same person must not perform on the same request |
| Second approver | The person or role required when the customer’s rule calls for another approval |
| Access scope | The controlled system or access reference covered |
| Authority method | The customer-approved way to confirm the instruction |
| Effective from | When the authority starts |
| Effective to | When it ends, or current |
| Customer reference | The authority form, email approval or other controlled record |
Ownership or right-to-enter checks made during an earlier call-out do not create permanent authority to order keys. Use the locksmith proof-of-ownership checks for the initial access decision, then use the customer’s current authority record for later key requests.
Treat the work order as a job reference
A purchase order or work order tells your team what job the customer wants processed. It does not, by itself, prove that the sender can approve access.
Link the work order to the authority record. Check the requester, approver, site, system, access reference, quantity and intended recipient. If one item falls outside the recorded authority, pause that item and ask the authorised customer contact.
Keep the documents in their lanes:
- The authority record controls permission.
- The work order controls the work.
- The key issue record proves the handover.
- The invoice records what was billed.
If extra authorised work is added after the accepted scope, record it as a variation before doing it. Do not rewrite the authority record to make the variation look pre-approved.
Set authority when strata or managing agents change
A change of strata manager or managing agent is a control point. Do not replace the old contact’s name with the new one and lose the history.
Close the outgoing contact’s authority period. Record the final date. Keep every approval they gave while their authority was current.
Add the incoming representative as a new authority record only after the customer confirms the approval chain. Use the customer’s own terms, whether that is owners corporation, body corporate, strata manager, managing agent or building manager. Do not assume those roles carry the same powers.
Pause new restricted-key requests while the handover is unclear.
Ask the customer to confirm:
- which sites the new representative covers;
- which systems or access groups they may approve;
- whether they may request, approve, receive or return keys;
- how your office should confirm their instructions; and
- when the new authority starts.
Record the answer as a new authority period. Do not backdate it to make an earlier request fit.
Give sites, systems and keys stable identifiers
Assign separate identifiers to the customer, site, key system, access group, physical key, controlled set, authority record, custody event and open action.
The identifier on the physical key must match the key asset record and work order. Do not reuse an identifier after a key is retired. Old keys can turn up years later. Reusing the number makes the old key look current.
Write down the naming rule. Keep it short enough for the bench and specific enough to prevent duplicate records.
Keep opening details off visible tags
Use a controlled identifier on the key or tag. Keep the street address, tenant name, room name and plain-language door details inside the protected record.
A person finding the key should not be able to read where it works. Your authorised staff should still be able to match the physical identifier to the protected access reference.
Track each key separately when individual custody matters. You can track a sealed emergency set as one unit only while the customer stores, issues and audits it as one unit. If keys can leave the set separately, assign each one its own asset record.
Build the locksmith key control register as linked records
Keep the site and key asset, authority, custody event and open-action records separate. Link them with stable site IDs, key IDs, authority record IDs, work orders and event references. The tables below hold the fields; the links preserve the history.
Copy-ready commercial key register structure
Use these blank fields when setting up the register. Join the sections with the site ID, key ID and linked references.
#### Site and key asset
| Field | Entry |
|---|---|
| Customer | [Legal customer name] |
| Site ID | [Stable site identifier] |
| Site address | [Address, state or territory, postcode] |
| Key-system reference | [Protected system identifier] |
| Key ID or set ID | [Physical controlled identifier] |
| Access reference | [Protected opening or access-group reference] |
| Key type | [Standard, controlled or restricted] |
| Custody state | [Under site control, issued or unresolved] |
| Condition | [Serviceable, damaged or unknown] |
| Lifecycle | [Active or retired] |
#### Restricted key authority
| Field | Entry |
|---|---|
| Authority record ID | [Stable identifier] |
| Site ID | [Site identifier] |
| Authorised person | [Name and customer role] |
| Permitted action | [Request, approve, receive or return] |
| Approval rule | [Required approval sequence] |
| Prohibited role combinations | [Actions that must be separated] |
| Second approver | [Name, role or not required] |
| Permitted access scope | [Controlled reference] |
| Confirmation method | [Customer-approved method] |
| Effective from | [Unambiguous date] |
| Effective to | [Unambiguous date or current] |
| Customer reference | [Authority document or approval record] |
#### Key issue record and later movements
| Field | Entry |
|---|---|
| Custody event ID | [Stable identifier] |
| Requester or request reference | [Person, authority request or purchase order reference] |
| Exact key IDs handed over | [Every physical identifier included in the handover] |
| Event | [Issue, transfer or return] |
| Previous event | [Event ID or first issue] |
| Previous holder | [Person or controlled location] |
| New holder | [Person or controlled location] |
| Authority record ID used for release | [Current authority record identifier] |
| Approved by | [Authorised customer contact] |
| Recipient confirmation | [Result, method and reference] |
| Released or accepted by | [Locksmith or office person] |
| Event date and time | [Unambiguous date and time] |
| Condition at event | [Serviceable, damaged or unknown] |
| Expected return date | [Date or not required] |
| Recovery owner | [Customer contact responsible for recovery] |
| Acknowledgement | [Method and reference] |
| Work order | [Job reference] |
#### Open action
| Field | Entry |
|---|---|
| Action ID | [Stable identifier] |
| Site ID | [Site identifier] |
| Key ID or set ID | [Physical identifier] |
| Problem | [Overdue, missing, damaged, duplicate or conflict] |
| Last known holder | [Person or controlled location] |
| Opened | [Date] |
| Action owner | [Name or role] |
| Next action | [Task and review date] |
| Customer decision | [Decision and authority reference] |
| Closure reference | [Event, work order or decision] |
| Closed | [Date or open] |
Put an authority gate before cutting
Check the live customer authority record before preparing the key. Match the authority record ID, requester, approver, permitted action, site, effective dates, protected access reference, quantity and intended recipient.
Run a separate check for any restricted-system ordering authority or registered signatory requirement. Match the system reference, ordering authority reference, authorised signatory and permitted key scope using the current records for that system. The customer’s authority to request or approve work does not replace a separate system ordering authority, and the system authority does not replace customer approval.
If either required authority chain is missing or does not match, stop the job. Record the mismatch and ask the correct authorised contact to resolve it before cutting.
Connect approved system scope to the job without exposing opening details. When the customer is still deciding what will be supplied, use the locksmith master key quote guide before creating asset records.
Match the physical key at the bench
Put the key, work order and protected record together. Read the identifier from the physical key. Match it to the asset record, system and approved access reference.
If the key on the bench carries a different identifier from the work order, stop the release. Open an action and find whether the mistake is on the key, job record or register.
Do the same when a returned key looks right but its identifier belongs to another site. Keep the expected key issued. Record the unexpected key separately until you identify its proper record.
Do not solve a mismatch by editing the register to fit what is on the bench. Check the source documents and have the register owner approve any correction.
Complete the key issue record during handover
Before releasing the key, match the person or controlled location in front of you to the intended recipient on the approved request. Use the customer-approved confirmation method recorded in the authority file. If the recipient or confirmation method does not match, stop the release and open an action.
The holder does not have to be a person. It can be a named security desk, controlled cabinet or other customer-controlled location. Record that location and the role responsible for it. Never leave the holder blank.
For a temporary issue, set an expected return date and name the customer contact responsible for recovery. The date is a trigger for follow-up. It is not proof of return.
If a call-out also produces replacement hardware or extra authorised work, keep the custody event linked to the job and use the emergency locksmith invoice process to bill the work without turning the key register into an invoice.
Append transfers and returns without deleting history
Inspect the physical identifier before accepting a return. Record the person or controlled location returning it, the staff member accepting it, the date, condition and preceding custody event.
If the wrong key is presented, do not mark the expected key as returned. Open a conflict action. The original holder remains the recorded holder until the correct key comes back or the customer makes an authorised decision.
For a direct transfer between employees, add a new transfer event. Name the previous holder and new holder. Record the approval and link the transfer to the earlier issue.
Do not edit the original issue so it names the second employee. That destroys the custody trail and hides the first handover.
Keep damaged and retired keys visible. Record whether the key was surrendered, retained under customer control or left missing. Link retirement or replacement to the customer decision and work order.
Work every overdue or missing key to a decision
An overdue key is still issued. Open an overdue action when the expected return date passes, but do not create a return event until the physical key is accepted.
Assign the follow-up to a named person. Record the next call, customer response and next review date. Keep moving the action until the key returns or the authorised customer contact decides what happens next.
For a missing key, record the last valid custody event. Ask the customer contact with the recorded authority to decide the response. Link any replacement, rekeying or access change back to the affected key without putting exposed door details into ordinary job notes.
A damaged key also stays in the history. Record its condition and physical status. Do not delete the asset because it can no longer be issued.
Move scattered client records into one controlled register
Set a go-live date for one controlled target register. On that date, make every old spreadsheet, inbox folder and paper list read-only and direct all new requests, approvals, issues, transfers and returns to the controlled register. Carry every unresolved gap into an open action.
Record where each imported entry came from. Mark it current only after a physical check or confirmation from a customer contact with recorded authority. Do not let an old spreadsheet become the live record just because it looks complete.
Import only data you can match to a customer, site, key, authority record or custody event. Do not guess which building an unidentified key belongs to.
Create an open action for every unresolved entry. That includes duplicate identifiers, blank holders, expired contacts, uncertain access references and keys that cannot be physically found.
Reconcile high-risk records first. Check restricted keys, active temporary issues, former staff holders and keys with conflicting site references. Ask the customer to confirm the current approval chain before processing another request.
When you move a client into the locksmith key control register, preserve the source reference for each imported record. If an old entry cannot be trusted, label it unresolved and arrange a physical check. A visible gap is safer than a confident guess.
Test the process on one live site
Choose one property. Nominate the register owner, confirm the customer’s approval chain and enter the active key assets without guessing at missing details.
Run the next real request through the locksmith key control register from authority check to bench check and handover. Use the locksmith job-control page when you need to connect this process to the rest of the work.
Then test one transfer and one return. If the register cannot show the earlier holder, current holder and next action without editing history, fix the structure before adding another site.