Author: Kaviarasan

Security guards and field supervisors spend their own money more often than most employees realise: fuel for a site-to-site run, parking at a client property, a replacement torch battery, a toll on a late callout. None of that gets paid back fairly unless the claim is captured on a form built to survive a payroll review, not scrawled on the back of a receipt. A reimbursement request form is what turns that improvising into a process.

A reimbursement request form is the document an employee completes to claim back money spent on the company’s behalf. It records what was bought, why, how much and who approved it, so the expense can be verified and added to the employee’s next pay run instead of being paid out ad hoc or disputed after the fact.

The problem: claims that cannot be checked

A security company running guards across several sites sees a steady trickle of small, legitimate expenses. The trouble starts when there is no standard way to claim them. One guard texts a photo of a receipt to a supervisor. Another hands over a paper slip at the end of the month. A third simply forgets, then raises it weeks later when the amount is harder to verify.

Without a consistent form, payroll cannot tell a genuine claim from a guess, cannot check it was actually approved and cannot tie it to a specific pay run with any confidence. That is how claims get paid twice, missed entirely or argued over after the payslip has already gone out.

Why it matters for a security company

Guards and supervisors are mobile by the nature of the job: multi-site patrols, gate duty at a client’s premises, emergency callouts outside a normal roster. Out-of-pocket spending is routine, not exceptional, which makes a repeatable claim process a payroll necessity rather than a nice-to-have.

A proper form also protects the company. A claim with a date, an amount, a reason and a named approver is auditable if a client or an internal review ever asks why a cost was paid. A claim with none of that is just a number someone remembers approving, which is a weak position to be in during any dispute. A consistent reimbursement request form turns routine out-of-pocket spending into a predictable payroll task rather than a monthly argument.

How it works: from claim to payslip

The form itself is only half the process. Once an employee submits it, a manager reviews the claim against the stated reason and the evidence attached, then approves or rejects it. An approved claim is not paid as a one-off transaction floating outside the normal pay cycle; it is added to the employee’s next payroll run as a specific line item, so it appears on the payslip alongside wages, overtime and any deductions for that period, with a clear record of which run it landed in.

That last point matters more than it sounds. A reimbursement that is approved verbally and “sorted out later” tends to either get paid twice because nobody remembers it was already settled, or missed entirely because nobody remembers it at all. Tying every approved claim to a specific run closes both gaps.

7 essential fields a reimbursement request form needs

1. Employee name and ID. Enough to identify who is claiming without relying on a supervisor’s memory.
2. Date of expense. The day the money was actually spent, not the day the form was filled in.
3. Site or shift reference. Which location, client site or shift the expense relates to, so it can be checked against a roster if needed.
4. Expense category. Fuel, parking, tools, equipment repair, meals on an extended shift and so on. A short fixed list is easier to review than free text.
5. Amount claimed. The exact figure, in the currency the claim was incurred in if the company operates across borders.
6. Reason or justification. A short explanation of why the expense was necessary for the job, not just what it was.
7. Approver name, decision and date. Who reviewed the claim, what they decided and when they decided it, so the claim has a clear audit trail before it ever reaches a pay run.

A claim missing any of these is harder to defend later. A reimbursement request form with all seven fields is a five-minute approval, not a month-end argument.

Common mistakes security companies make

Most of what goes wrong with a reimbursement request form comes down to one of four habits.

No fixed expense categories. Free-text “what did you buy” fields turn into a mess of inconsistent entries that nobody can total up by type at the end of the quarter.

Approval happens after the money is already spent and already reimbursed. Verbal approval followed by an informal cash handout removes the audit trail the form exists to create.

Claims arrive after the payroll run has already closed. A form with no deadline tied to the pay cycle guarantees a backlog of “catch-up” claims that disrupt the next run instead of the one they belonged to.

Treating reimbursement as a one-off payment instead of a payroll line item. A reimbursement paid outside the normal pay run, by cash or a separate bank transfer, has no paper trail connecting it to a specific payslip, which is exactly the dispute this form is meant to prevent.

How AVES handles it

AVES does not treat an approved reimbursement request form as paperwork that happens outside payroll. Once a claim is approved, it is added as a line item to the employee’s next payroll run, the same run that calculates wages, overtime and any deductions for that period, so it shows up on the resulting payslip rather than sitting in an unexplained cash drawer. That keeps the claim tied to one specific pay cycle, which is the detail that stops it being paid twice or forgotten.

AVES does not replace the claim form itself with a dedicated receipt-scanning app; the fields above are what a company should capture before a claim ever reaches payroll. What AVES is responsible for is making sure that once a claim is approved, it reliably reaches the right pay run and the right payslip.

FAQ

Is a reimbursement request form the same as an invoice?

No. An invoice is a bill one party sends another for goods or services. A reimbursement request form is an internal claim an employee submits to be paid back for money they already spent on the company’s behalf.

Should reimbursements be paid separately from a wage payment?

It is cleaner to add an approved reimbursement to the employee’s next scheduled payroll run rather than paying it out as a separate transaction, because that keeps one record, on one payslip, instead of two disconnected payments to track.

What happens to a claim that is rejected?

It should be recorded as rejected, with a reason, rather than simply deleted, so there is a record of why it was not paid if the employee queries it later.

Who should approve reimbursement claims?

Typically the employee’s direct supervisor or site manager, someone close enough to the work to judge whether the expense was reasonable, before it is passed on to payroll for the next run.

Does a reimbursement need a receipt?

Most security companies require some form of proof for anything beyond a trivial amount. A form with no evidence field makes every claim a judgement call on trust alone.

Where this fits in your payroll loop

A reimbursement request form is the first step in a chain that runs from a guard’s out-of-pocket spend through to a correctly itemised payslip. The same discipline that keeps a performance development plan or an employee write-up form auditable, a named approver, a date, a clear record, applies here too. On the finance side, the same approved-claim logic is what keeps an accounts receivable ageing report accurate when a client contract passes costs through to billing. If your current process for any of this is still a logbook and a filing cabinet, the same gap shows up in a security guard logbook that nobody can search.

Book a 30-minute demo and we will show you exactly how an approved reimbursement claim lands on the right payroll run and the right payslip: book a demo. Prefer to explore first? Start a free trial. Follow AVES on Instagram for product updates.

Author: Kaviarasan, AVES Security content team. Last updated: 13 October 2026.

A security incident log template is the running register a site uses for every incident it records over time, not a single report. Where an incident report form captures one event in full, the log is the chronological list that lets a supervisor see every entry at a glance: what happened, when, who responded and whether it is closed.

Most sites already have an incident report form. What a lot of them are missing is the log that sits above it: the single page, book or sheet that lists every incident a site has had this month, in order, so a supervisor does not have to open twenty separate report files to answer “how many incidents did we have in March, and which ones are still open.” That list is the security incident log, and the columns it uses decide whether it is useful six months from now or just a pile of entries nobody can search.

This guide covers the eight columns a security incident log template needs, the mistakes that turn a log into a liability instead of a record and how AVES replaces the paper version with entries that cannot be rewritten after the fact.

Why a security incident log matters

A single incident report answers “what happened in this one case.” A log answers a different question: “what has been happening on this site.” Without one, a supervisor handing over to a new shift, briefing a client or preparing for an insurance review has to reconstruct a timeline from loose paperwork, which is slow and easy to get wrong. This is exactly the gap a security incident log template is built to close.

A proper log also protects the site when something is disputed later. If a client asks whether a particular type of incident has happened before or how many are still open, the answer should be a quick look down one list, not a search through a filing cabinet. And because a log is chronological, it surfaces patterns a single report never will, for example the same location showing up three times in a month, which is a sign worth acting on before it becomes a fourth incident.

How a security incident log works

The log itself is simple: one row per incident, added as it happens, never removed. Each row is a short summary, not the full case file. The detail, the photos, the findings, live in the incident report behind it. The log is the index; the report is the record.

That split in a security incident log template is what makes it fast to scan. A supervisor reviewing a week’s incidents should not have to read eight full reports to get a sense of what happened. They should be able to run down eight rows, spot the one marked still open and go straight to that report. A log that tries to hold the full narrative in every row stops being a log and becomes a duplicate of the report file, which defeats the point.

The 8 columns a security incident log template needs

These are the columns that keep a log useful rather than decorative, grounded in how AVES’s incident and safety modules already capture this information.

1. Date and time. When the incident happened, not when it was written up. AVES timestamps every incident, safety and defect entry at the point of submission, so the log reflects the real sequence of events.
2. Incident type. Whether the entry is a general incident, a security incident or a property/hotel-type event. AVES’s incident forms are split across these categories, which is what lets a log be filtered down to just one type when that is all a reviewer needs.
3. Location. Where it happened, specific enough to spot a pattern. A log that just says “on site” cannot tell you that the same loading dock has come up three times this quarter.
4. Short description. One or two lines, enough to know what kind of incident it was without opening the full report. This is the summary row, not the case file.
5. Evidence captured. Whether photo, video or audio evidence exists for the entry. AVES’s incident forms use a six-sided photo capture alongside video and audio, so the log can show at a glance which entries have supporting evidence and which do not.
6. Findings and action taken. What was done in response, even as a short note. AVES’s incident and defect/safety forms both carry a findings-and-actions field, which is what a log column should summarise rather than the signature line some paper sheets use instead.
7. Reported by and reviewed by. Who raised it and who signed it off. AVES ties every incident, safety report and investigation entry to a named reporter, and investigation-type entries carry a separate approvedBy reviewer, so responsibility for both the report and the review is on record.
8. Status, including whether a police report was filed. Open, under investigation or closed, plus a flag for cases that went to police. AVES’s incident forms carry a police-report field directly, so a log does not need a separate note to show which entries left the building.

Those eight columns are what turn a list of incidents into something a supervisor can actually use: a column for when, what kind, where, what happened, what evidence exists, what was done, who is accountable and where it stands now.

Common mistakes that make a security incident log useless

A security incident log template fails for a handful of predictable reasons. The most common mistake is no status column. Without one, every entry looks permanently unresolved, and a supervisor cannot tell an open case from one that was closed out weeks ago just by looking at the row.

The second is collapsing the log into the report. Some sites try to write the full narrative into every log row, which makes the log slow to scan and defeats its purpose. The log should point to the report, not replace it.

The third is no evidence flag. If a log cannot show which entries have supporting photo, video or audio evidence, a reviewer has to open every single report to find out, which is exactly the extra step a log is meant to save.

The fourth is a paper or shared-spreadsheet log that can be edited after the fact. A row that can be quietly changed is not a record, it is a draft. Entries need to be stamped with who logged them and when, and they need to stay that way once submitted.

How AVES supports the log, honestly

AVES does not ship a single standalone “incident log” screen separate from its incident, safety and investigation forms. What it does is capture every incident, defect and investigation entry as a timestamped, named record the moment it is submitted, through the six-sided photo and video and audio evidence capture, a findings-and-actions trail and a police-report field where relevant. Investigation-type entries add a separate approvedBy reviewer on top of the original reporter. That is what any security incident log template in AVES is actually built from.

That combination, taken together across a site’s incidents, is the log: a chronological, filterable list of every entry, each one backed by its own full report, with nothing in it that can be silently rewritten after submission. There is no signature-image field anywhere in AVES; sign-off is always a named accept, decline or submitted action with a date and time attached, which is a more searchable trail than a scrawl ever was.

FAQ

What is a security incident log template?

It is a running list of every incident a site records, one row per entry, covering when it happened, what kind it was, where, a short description, whether evidence exists, what was done, who is accountable and its current status. It sits above the full incident report rather than replacing it.

What is the difference between an incident log and an incident report?

A report captures one incident in full: the narrative, the evidence, the findings. A log is the index across every incident a site has had, built from short summary rows so a supervisor can scan a period at a glance.

How many columns should a security incident log have?

Eight is enough for most sites: date and time, incident type, location, short description, evidence flag, findings and action, reported by and reviewed by, plus status. Fewer than that and a log usually loses the ability to show what is still open.

Can a spreadsheet work as a security incident log?

It can for a single site with a low incident count, as long as someone actively maintains the status column. It breaks down once entries need to be tied to the original report, once more than one person edits it or once a client or an insurer needs a record that cannot be quietly altered after the fact.

Does AVES include a police-report field?

Yes. AVES’s incident forms carry a police-report field alongside the six-sided photo, video and audio evidence capture, so a security incident log template built from these entries can show which incidents went to police without a separate manual note.

Related reading

• Incident Reporting Software: how AVES captures incidents end to end
• Incident Report Form: the 8 fields every report must include
• Investigation Report Template: structuring a security investigation
• Near Miss Report Form: 8 fields every report must include
• Security Guard Logbook

See it in action

Book a 30-minute demo and we will show you how AVES timestamps and ties together incident, safety and investigation entries so a log always reflects the real record behind it. Book a demo or start a free trial.

Internal links: Incident Reporting Software · Incident Report Form · Investigation Report Template · Near Miss Report Form · Security Guard Logbook. External: AVES on Instagram (DoFollow).

Contract management software (AEO definition): for a security company, contract management software is the system that stores each client’s SLA terms, billing model and payment terms against one record, so billing and service delivery can be checked against what was actually agreed.

The problem with contracts living in a filing folder

A security contract is not just a signed PDF. It sets the response time a client expects, how many patrols per shift are owed, a minimum attendance percentage and a penalty if that is breached, plus the billing model and payment terms the invoice should follow. When that detail only lives in a filed document, nobody checking a monthly invoice or a missed patrol can quickly confirm what was promised.

The result is a slow drift: a site gets billed on the wrong rate card for months, a contract auto-renews without anyone noticing the SLA terms changed or a client disputes a penalty clause because operations never had the contract terms in front of them when the breach happened.

Why it matters

Security contracts carry real financial exposure. A penalty-per-breach clause only protects the client if someone is actually tracking attendance against the minimum percentage it refers to. A billing model that is not applied consistently means invoices do not match what the client agreed to pay, which is the fastest way to create a payment dispute.

It also matters operationally: PO tracking and payment terms determine when a company can expect to be paid, and an auto-renew clause that nobody is watching can lock in outdated terms for another year.

Multi-site clients make this harder still. A single contract can cover several sites under one SLA, each with its own patrol count and minimum attendance percentage, so contract management software has to hold those site-level terms against one client record rather than forcing a separate filed document per site. Without that, a billing dispute on one site means checking a different document to the one covering the client’s other sites and the penalty-per-breach clause risks being applied against the wrong site’s attendance figures.

How it works in AVES

AVES is not general-purpose contract management software built for every industry. It keeps each client’s contract terms attached to the same record that drives billing and service tracking, inside the Finance module:

• Clients hold the core record for each client relationship.
• Contracts store SLA terms (response time, patrols per shift, minimum attendance percentage, penalty per breach), the billing model (per guard per month, per hour, per shift or fixed monthly), the billing cycle, payment terms, PO tracking, auto-renew and any attached documents.
• Rate cards and tax profiles sit per organisation, so the billing model on a contract maps to an actual rate rather than a manual figure typed at invoice time.
• Invoices are generated from real attendance records, so the billing model on the contract has something concrete to apply to.

Because the contract record and the invoice record sit in the same module, a billing dispute can be checked against the actual SLA terms rather than a filed document nobody has open.

What contract management software must track

1. SLA terms: response time, patrols per shift and minimum attendance percentage, the measurable commitments a client will hold the company to.
2. Penalty per breach: what happens and how it is calculated, if an SLA term is missed.
3. Billing model: per guard per month, per hour, per shift or fixed monthly, set once and applied consistently.
4. Billing cycle and payment terms: how often invoices go out and how long the client has to pay.
5. PO tracking: the purchase order reference an invoice needs to match, where a client requires one.
6. Auto-renew status: whether the contract rolls over automatically and on what terms.
7. Attached documents: the signed contract itself, kept against the record the billing model reads from.

Common mistakes

• Billing from memory instead of the contract record. If the billing model lives only in someone’s head, a staffing change means the next invoice quietly uses the wrong rate.
• Treating SLA terms as a one-time read. A penalty-per-breach clause is only enforceable if attendance is actually measured against the minimum percentage it names.
• Letting auto-renew pass unreviewed. A contract that rolls over without a review can lock in a rate card or SLA term that no longer fits the site.
• Losing the PO reference. An invoice that does not match a client’s PO number is the easiest invoice for their accounts-payable team to reject.

FAQ

Is AVES general-purpose contract management software?

No. AVES keeps contract SLA terms, billing model and payment terms attached to the same client record that drives attendance-based invoicing for a security company, rather than acting as a standalone enterprise CLM platform.

Can a contract set a different billing model per client?

Yes. Each contract’s billing model can be per guard per month, per hour, per shift or fixed monthly, applied with that client’s own rate card.

Does AVES track SLA breaches automatically?

SLA terms such as minimum attendance percentage are stored on the contract and attendance is measured through geofenced attendance records, so a breach can be checked against the contract’s own penalty clause.

What happens when a contract auto-renews?

Auto-renew is a setting on the contract record, so whether a contract rolls over and on what terms, is visible on the same record rather than left to a filed document.

Can a client’s signed contract document be stored with the record?

Yes, attached documents keep the signed contract against the same record the billing model and SLA terms are read from.

Where this fits in the billing loop

A contract’s billing model only means something once it is applied to real hours worked, which is why it connects to geofenced attendance and feeds the same accounts receivable aging report that tracks whether invoices built from the contract get paid on time. Payroll built from the same attendance record is covered in the payslip template guide and for the credit side of invoicing, see credit note template.

For the operational record a contract’s SLA terms get measured against, see the security guard duty roster.

Follow AVES on Instagram for more guides like this one.

CTA

Ready to see contract SLA terms, billing and attendance tied to one client record? Book a 30-minute demo and we will show you a contract-to-invoice walkthrough.

Prefer to explore first? Start a free trial.

Payslip template (AEO definition): a payslip template is the fixed layout a payroll run uses to turn one guard’s hours, pay rate, allowances and deductions into a single document that shows exactly how their net pay was calculated for the period.

The problem with a generic payslip template

Security guarding does not pay like a desk job. One guard might work a day shift, a night differential and two hours of overtime covering a missed handover, all inside the same week. A generic payslip template built for salaried office staff has one line for “basic pay” and nowhere to show where the overtime hours came from or why a deduction was applied.

When a security company runs payroll from a spreadsheet, the template usually survives the first few guards and then breaks: someone copies last month’s formula into the wrong row, an allowance gets applied to a guard who left the site or a reimbursement claim never makes it into the final number. The guard notices before payroll does, because it is their money.

Why it matters

A payslip is the one document every guard reads closely every month. Get it wrong and the dispute lands on a supervisor’s desk, not an HR inbox, because guards escalate pay questions to whoever is in charge of their roster. Get it right consistently and payslip queries stop being a monthly fire drill.

It also matters for the business side: a clean, consistent payslip template is what makes a payroll run auditable. If a client or a labour inspector asks how a specific guard’s pay was calculated for a specific week, the answer needs to come from the record, not from someone’s memory of a spreadsheet formula.

How it works in AVES

AVES does not treat payroll as a bolt-on spreadsheet. The payroll module is built around a few connected pieces:

• Salary templates set the base structure for a role or site, so a new guard is added to payroll with the correct pay structure already applied rather than typed from scratch.
• Payroll calendar defines the pay periods the whole company runs on, so every payslip for a given month covers the same dates.
• Payslips are generated per guard per period from that salary template, combined with the hours actually logged for that guard.
• Reimbursements (travel, uniform, equipment and similar claims) are added to the run rather than paid separately and left off the record.
• Payroll engine with an approval workflow means a payroll run does not go straight to payout. It is reviewed and approved first, with bank files produced for the approved run.
• FinalSettlement handles the exit calculation when a guard leaves, so a leaver’s last payslip is not a manual one-off.

Because AVES also runs geofenced attendance, the hours that feed a payslip come from the attendance record for that guard’s shifts, not from a separate timesheet someone re-types into payroll. That link is what keeps a payslip template defensible: the number on the payslip traces back to a logged shift, not an estimate.

The 7 fields a payslip template must include

1. Guard identity and pay period: name, staff ID, site or post and the exact date range the payslip covers.
2. Basic pay: the base rate from the guard’s salary template for the period, before anything else is added or removed.
3. Overtime and shift differentials: overtime hours and any night, weekend or holiday differential, shown as a separate line so a guard can check it against their actual shifts.
4. Allowances: any fixed allowance the salary template applies (uniform, travel, site allowance), listed individually rather than folded into basic pay.
5. Reimbursements: one-off claims approved and included in this specific run, not carried over silently to next month.
6. Deductions: statutory and other deductions, itemised rather than shown as a single “deductions” total.
7. Net pay and approval trail: the final figure, plus a record that the run was approved before it was paid, so the payslip is not just a claim, it is a reviewed calculation.

Common mistakes

• Treating overtime as a manual add-on. If overtime is typed in after the fact instead of calculated from logged hours, it is the first thing a guard will dispute and the first thing that is hard to defend.
• Skipping the approval step. A payroll run that goes straight from calculation to payout has no checkpoint for catching a wrong rate or a duplicated reimbursement before the money moves.
• Losing reimbursements between systems. When expense claims are tracked somewhere other than payroll, they either get paid twice or missed entirely.
• Improvising the exit payslip. A guard’s final pay, including any outstanding dues, needs the same rigour as a regular payslip, not a rushed manual calculation on their last day.

FAQ

What should a security guard payslip template include that a standard template does not?

It needs a clear breakdown of overtime and shift differentials, since guard pay varies week to week with roster coverage in a way a fixed salaried template does not account for.

Does AVES calculate payroll automatically from attendance?

AVES payroll draws on the geofenced attendance record for logged hours and payslips are built from the salary template plus that attendance data, reimbursements and deductions for the period, with a payroll engine and approval workflow before payout.

How does AVES handle a guard’s final pay when they leave?

Through FinalSettlement, a dedicated exit-settlement process, rather than a manual one-off calculation.

Can allowances and reimbursements differ by site?

Salary templates are set per role or site, so allowances can be structured to match the guard’s actual posting and reimbursements are approved claims added to the specific run.

Does a payslip need to show an approval trail?

Yes. A payroll run that has been through an approval workflow before the bank file is produced gives the business a defensible answer if a payslip is ever queried.

Where this fits in the payroll loop

A payslip is the last step in a chain that starts with attendance. Guards clock in and out through geofenced attendance, that verified time feeds the payroll run described above and the same billing-relevant attendance record is what a security company’s accounts receivable aging report traces back to on the client-billing side. Payroll and client billing are separate modules in AVES, built on the same underlying attendance record rather than two disconnected spreadsheets.

For the wider staff-documentation picture, see how AVES handles performance development plans and employee write-ups and for the operational record this payroll data sits alongside, see the security guard logbook.

Follow AVES on Instagram for more guides like this one.

CTA

Ready to see how AVES turns verified attendance into an auditable payslip? Book a 30-minute demo and we will show you an actual payroll run from attendance to payslip.

Prefer to explore first? Start a free trial.

What is a toolbox talk? A toolbox talk is a short, focused pre-shift safety briefing, usually five to ten minutes, where a supervisor covers one specific hazard, recent incident or procedure with the guards going on duty. A toolbox talk template is the reusable structure that keeps these briefings consistent, so nothing important gets skipped and there is a record the talk actually happened.

The problem: talks that leave no trace

Most security sites run toolbox talks the same informal way: a supervisor gathers the outgoing or incoming shift, says a few words about “being careful out there,” and moves on. There is no fixed structure, no record of what was actually covered, and no way to check whether the same three guards missed the last four briefings.

When an incident happens later and a client or insurer asks whether guards were briefed on a hazard beforehand, a verbal-only toolbox talk gives a security company nothing to point to. The talk may well have happened, it just cannot be proven.

Why a structured toolbox talk template matters

A toolbox talk template solves three problems at once:

1. Consistency across sites. A guard company running several sites cannot rely on each supervisor remembering to cover the same ground. A template means a hazard review at Site A looks the same as at Site B.
2. An audit trail. Clients, auditors and insurers increasingly expect proof of routine safety communication, not just proof of training. A dated, topic-by-topic record answers that.
3. Faster onboarding. New supervisors can run a competent toolbox talk on day one if the structure is already written down, rather than improvising.

The 7-topic toolbox talk template

Use this as the running order for a pre-shift talk. Not every topic needs equal time, a two-minute mention is fine for anything that has not changed since yesterday.

1. Site-specific hazard of the day, the one thing most likely to cause harm on this shift (a broken light on a patrol route, ongoing construction, a slippery entrance after rain).
2. Weather or site conditions, anything that changes how guards should move or what they should wear or carry.
3. Recent incident or near-miss review, a short, blame-free recap of anything logged since the last talk, and what to watch for as a result.
4. PPE and equipment check, confirm the right kit (radio, torch, ID, any site-mandated PPE) is on hand and working.
5. Patrol route or checkpoint hazards, anything that has changed on the route since the last patrol (a blocked exit, a new checkpoint, restricted access).
6. Emergency procedure reminder, a rotating reminder of one procedure (evacuation point, code activation, who to call first) rather than repeating the full manual every time.
7. Open floor and acknowledgement, guards ask questions, and the supervisor notes who attended and confirms understanding.

What to record for every toolbox talk

A toolbox talk is only as good as its record. Capture at minimum:

• Date and shift
• Who delivered the talk
• Guards who attended
• The topic(s) covered that day
• Any question or concern raised
• Any follow-up item created, and its status until it is closed

Common mistakes that undermine toolbox talks

• Running the same generic talk every day. Guards switch off if the content never changes; rotate topics against the 7-point toolbox talk template above.
• No written record. A verbal-only talk cannot be produced later as evidence that a hazard was actually communicated.
• No follow-up close-out. A hazard raised in a talk and never checked again is worse than not raising it, it creates a paper trail showing the company knew and did not act.
• Treating it as a formality. A rushed thirty-second talk with no engagement satisfies nobody’s audit and does not actually change guard behaviour.
• No accountability for attendance. If a company cannot say who was in the room, it cannot show the guard on a later incident was actually briefed.

How AVES supports the record, honestly

AVES does not ship a canned library of toolbox talk scripts, that is not something to claim here. What AVES does ship is the record layer a toolbox talk template needs around the talk itself:

• The Daily Briefing module lets a supervisor log guard attendance by name, department and designation, a live property overview of site conditions, and a topic-and-description field for whatever was covered, exactly the structure a toolbox talk needs, timestamped and searchable later.
• Follow-up items raised during a talk go into the module’s follow-up field, tracked by status (pending, in progress, resolved) until someone closes them out, so a hazard mentioned once does not quietly disappear.
• The Security Meeting module can schedule a recurring toolbox-talk slot with attendance tracking, for sites that want it as a standing calendar entry rather than an ad-hoc gathering.

None of this writes the talk for a supervisor. It is the difference between saying a briefing happened and being able to show, by date and name, that it did.

Use this toolbox talk template at your next shift change

Print or paste the 7-topic toolbox talk template above into a supervisor’s handover pack, and run through it before every shift starts. A toolbox talk template only works if it is actually used, so keep it short enough that supervisors reach for it instead of skipping it. Most sites laminate a one-page version for the guard hut, then log the topic and any follow-up in Daily Briefing once the talk is done. Over a few weeks, this toolbox talk template becomes a habit rather than a chore, and the record it leaves behind is what turns a five-minute conversation into evidence a company can actually use.

Frequently asked questions

How long should a toolbox talk last?

Five to ten minutes is typical. Longer talks lose attention; the goal is one clear topic delivered well, not a lecture.

Who should run a toolbox talk?

Usually the shift supervisor or site lead, someone who knows the site’s current hazards and can answer questions on the spot.

How often should toolbox talks happen?

Most sites run one per shift change or at minimum daily. Higher-risk sites (construction-adjacent, night patrols, active incidents) often run them more frequently.

What is the difference between a toolbox talk and a daily briefing?

A daily briefing is the administrative record of a shift handover, attendance, site conditions, open items. A toolbox talk is the safety-focused conversation itself, usually a single topic. In practice, many sites log the toolbox talk topic and follow-up inside their daily briefing record rather than keeping two separate systems.

Can a toolbox talk replace formal safety training?

No. A toolbox talk reinforces and reminds; it does not substitute for the initial training a guard needs before starting a role.

Related reading

• Security Guard SOP: how to structure procedures guards actually follow
• Daily Briefing: the missing piece every security team overlooks
• Shift Handover Checklist: what every outgoing guard must log
• Church Security Checklist: 6 areas to cover
• Near Miss Report Form: 8 fields every report must include
• Security Guard Logbook

See it in action

Book a 30-minute demo and we will show you how Daily Briefing logs a toolbox talk’s topic, attendance and follow-up in one searchable record: Book a demo

Prefer to explore first? Start a free trial

Follow AVES on Instagram

Investigation report template: a structured document security teams use to record how a security investigation was conducted, what evidence was reviewed and who approved the findings, so the write-up holds up if it is challenged later.

A security investigation is only as strong as its paper trail. If a workplace theft, access breach or guest complaint ends up in a disciplinary hearing, an insurance claim or a legal dispute, the first thing anyone asks for is the investigation report. A vague summary email will not hold up. A structured template does.

Why a loose write-up fails

Security teams that skip a template tend to lose the same things every time: no record of which cameras or DVR footage were actually reviewed, no timestamp on when the investigation started versus when the incident happened, and no named sign-off showing who approved the conclusion. Without an investigation report template, six months later when someone asks “who looked into this and what did they find”, there is nothing but memory.

Investigation Report Template: What It Must Record

This investigation report template needs to cover the full chain from intake to sign-off, so the investigation report template is usable in a hearing rather than just a narrative paragraph.

• Case reference and date opened — a unique investigation ID and the date the case was logged, separate from the date of the underlying incident.
• Complainant / source intake — who raised it, how (verbal report, form, escalation from a guard), and their initial statement.
• Item or area under investigation — what was lost, damaged or breached, with location and time window.
• Evidence reviewed — DVR/monitor/camera review log: which cameras, which time ranges, what was seen. This is the section most loose write-ups skip entirely.
• Suspect / witness questioning — who was interviewed, when, and a summary of what they said.
• Supporting documents and images — attached evidence, photos of the affected item or area, any supporting paperwork.
• Findings — what the investigation concluded, stated plainly, separate from opinion.
• Approval sign-off — named approver, date and time, closing the case.

How AVES Supports an Investigation Report Template

AVES supports this investigation report template through two linked modules rather than a single free-text field. The Investigation Diary holds the working log: the investigation entry itself, a DVR/monitor/camera review record (which footage was checked and what it showed), and an approvedBy sign-off that closes the case with a name, date and time attached. The Lost Investigation module handles the intake side for loss-specific cases — complainant details, the item under investigation, suspect and witness questions and answers, and attached lost-item images or supporting documents.

Between the two, every section of the template above maps to a real field: intake, evidence review, questioning, supporting documents and sign-off are captured in the system rather than left to whoever wrote the email. Because entries are timestamped and the approval step is a discrete action, the finished record shows exactly when the case was opened, what was checked and who closed it — the three things a challenged investigation gets asked for first.

Common Mistakes With an Investigation Report Template

• Recording the conclusion but not the evidence trail. “Reviewed footage, nothing found” is not a review log — note the camera, the time range and what was actually visible.
• No separation between the complaint and the findings. Mixing what was reported with what was proven weakens the report if it is contested.
• Missing sign-off. An investigation without a named approver and closing date and time reads as unfinished, even if the work was done.
• Treating it as a one-off document. A template used inconsistently produces reports of wildly different quality — the value is in every case following the same structure.

FAQ

What should be in a security investigation report template?
Case reference, intake details, the area or item under investigation, an evidence review log (camera/DVR checks), witness and suspect questioning notes, supporting documents, findings, and a named approval sign-off with date and time.

How is an investigation report different from an incident report?
An incident report captures what happened at the time it happened. An investigation report documents the follow-up work — what was reviewed, who was questioned and what was concluded — and can be opened well after the original incident.

Who should approve an investigation report before it is closed?
A supervisor or manager with authority over the case, recorded with their name, date and time, so the closed case shows exactly who signed off.

Who needs an investigation report template

Any security team that handles theft, access breaches, guest complaints or internal disciplinary matters needs a repeatable investigation report template — not just large sites. A single warehouse with one security officer benefits just as much as a multi-site operation, because the moment a case is questioned, the question is never “did you investigate this” but “can you show me how”. A consistent investigation report template answers that question every time, regardless of site size.

Property managers, retail loss-prevention teams, facilities security and contract guarding companies all rely on the same underlying structure: an intake, an evidence trail, a questioning record and a named sign-off. The specific fields shift slightly by industry, but the investigation report template shape stays the same.

Investigation report template vs incident report: what’s the difference in practice

Teams often confuse the two. An incident report is filed at the time something happens — a break-in, an injury, a policy breach — and captures the immediate facts. An investigation report template is used afterwards, when someone needs to establish what actually occurred, who was involved and whether the initial account holds up. A single incident can generate one incident report and, if it escalates, a full investigation report built from that incident report plus camera review, witness statements and supporting evidence. Using an investigation report template only for genuinely investigated cases — not every minor incident — keeps the record meaningful instead of diluted.

Follow AVES Security on Instagram for more security operations tips.

---

Want to see how AVES structures investigation logging and evidence review for your team? Book a 30-minute demo and we’ll walk through the Investigation Diary and Lost Investigation modules on the actual screen. Prefer to look around first? Start a free trial.

Related reading: incident reporting software, incident report form: 8 fields every report must include, witness statement form, near miss report form, and for the daily record that feeds every investigation, the security guard logbook.

A key sign out sheet is a running log that records who took a key, when they took it, when it is due back, and whether it was returned. It turns shared keys into an accountable custody trail instead of a set of guesses about who last held the master.

Every site runs on keys. A master set, a server-room key, a gate padlock key, a store cupboard, a set of spares in the guardhouse drawer. The moment more than one person can pick up a key, someone has to be able to answer a simple question: who has it now, and who had it last. A key sign out sheet is how that question gets a real answer instead of a shrug.

Done well, a key sign out sheet is the difference between “the server-room key is missing and nobody knows who touched it” and “the key went out to Officer Rai at 19:04, was due back at 07:00, and was returned to the incoming supervisor at 06:52.” This guide covers the eight columns a key log actually needs, the mistakes that make one useless, and how AVES turns the paper version into a system that will not let a key quietly disappear.

Why a key sign out sheet matters

Keys are cheap to cut and expensive to lose. A single lost master key can force a lock change across a whole floor or site, and the replacement cost is the smallest part of the bill. The real exposure is accountability. When a client asks who had access to the plant room on Tuesday night, “we think it was the night team” is not an answer, it is a liability.

A proper key sign out sheet does three things at once. It fixes responsibility, so the person holding a key is on record by name. It surfaces problems early, because an overdue key shows up before it becomes a lost key. And it creates a defensible record, so when a key goes missing you can show exactly when it left, who signed for it, and what happened next. That record is what protects the guard, the supervisor and the company when a dispute lands.

How a key sign out sheet works

The flow is simple and it is the same on paper or in an app. A key is requested, it is issued to a named person, the issue is stamped with the time, and the entry stays open until the key is returned and checked back in. At any moment a key is either out or in, and every change of hands is tied to a person and a timestamp.

Paper handles the first half of that well enough. Where it falls down is the second half, the return. A paper sheet has no way to flag a key that never came back, no way to tie a loss to a recorded fine, and no way to stop a row being quietly rewritten. That is the gap a system closes, and it is worth understanding the columns first because the columns are the same either way.

The 8 columns every key sign out sheet needs

A key log is only as good as the fields it forces people to fill in. These are the eight that matter, mapped to how AVES records them in its key control workflow.

1. Key identifier or type. Which key is going out, named so it cannot be confused with another. AVES records a key type against each key so “master B” and “store cupboard 3” are never mixed up. Vague entries like “the key” are useless when there are twenty on the board.
2. Availability status. Whether the key is on the board and free to issue, or already out. AVES tracks key availability so a supervisor can see at a glance what is in and what is out before promising a key to anyone.
3. Issued to. The named person the key is going to. AVES captures who the key is requested to, so a key is tied to an individual and not to a shift or a team.
4. Accepted by, with date and time. Who actually took the key and when. AVES stamps the handover with the accepting person plus the accepted date and time, so the moment a key changes hands is on record to the minute, not just to the day.
5. Returned by. Who brought the key back and closed the loop. AVES records the returning person against the entry, so the return is a named action rather than an assumption that it must have come back.
6. Expected return, and overdue flag. When the key is due and whether it has passed that point. This is what lets a supervisor chase an overdue key before it becomes a lost key, which is the whole point of a log rather than a list.
7. Loss trail. What happens when a key does not come back. AVES records a lost date and, through the same workflow, a recorded fine amount, the person who issued the fine, and a receipt number, so a loss is documented and closed rather than noted and forgotten.
8. Status. Whether the entry is open, returned or lost. AVES carries a status on every key entry so the log always shows the true state of each key, and an open entry is a live question, not a stale row.

Those eight columns are the spine of any template, whether you build it in Excel, print it as a PDF, or run it in an app. If your current sheet is missing the return column and the status column, it is a sign out sheet in name only, because it can tell you what left but never what came back.

Common mistakes that make a key sign out sheet useless

The most common failure is no return column. Plenty of sheets record beautifully who took which key and then have nowhere to record that it came back, so every key looks permanently checked out and the log tells you nothing.

The second is no expected-return or overdue view. If nothing flags a key as late, a missing key is only discovered when someone needs it, which is always the worst possible moment. An overdue flag turns a lost key into an overdue key you can still chase.

The third is an editable, unstamped record. A paper row can be rewritten and a shared spreadsheet can be quietly changed, which is exactly the wrong property for a custody record. Entries need to be stamped with who and when, and they need to be hard to alter after the fact.

The fourth is treating a signature scribble as proof. A signature on paper proves very little six months later. It is worth being clear here: AVES does not capture a signature image. Instead, sign-off is an accept, decline or submitted action tied to a named user with a date and time, an audit trail rather than a scrawl, which is both harder to forge and easier to search.

How AVES turns the key sign out sheet into a system

AVES runs keys through a dedicated key control workflow rather than a loose form. A key is requested, issued to a named person, and returned, with each step tied to a user and a timestamp. When a key is not returned, the same workflow records the lost date, a fine amount, the person issuing the fine and a receipt number, so the loss is handled as a closed process rather than a note in a margin.

The point is not the individual field names. It is that every key movement is tied to a named person and a timestamp, the return half of the loop is enforced rather than optional, and the record cannot be quietly rewritten. That is what a paper sheet can never give you: not a prettier form, but a log you can actually stand behind when a client asks who had the key.

One honest note on scope. AVES records these key movements as they happen through the guard app, with the request, issue, return and lost-key trail described above. It records each key as it moves rather than presenting a single self-reconciling asset register of every key on site. What ships today is the accountable trail for each key as it is issued and returned.

Key sign out sheet vs a key control policy

A key sign out sheet is the running sheet you fill in every time a key changes hands. A key control policy is the rulebook behind it – who may hold which keys, who authorises an issue, how long a key can be held and how often the board is audited. This page is the sheet itself: the columns and a filled example you can copy. For the policy, authorisation levels and audit cadence that sit around it, see our full guide to key control.

Key sign out sheet template: a worked example

Here is how the eight columns look filled in for a single day on one board. Notice the second row: the key is out past its expected return with no return time, so it should flag as overdue – the one thing a paper sheet can never do for you.

Key	Availability	Issued to	Accepted (date / time)	Expected return	Returned by (time)	Status
Master B	Out	Officer Rai	22 Sep, 07:04	22 Sep, 15:00	Officer Rai, 14:52	Returned
Server room	Out	Officer Lee	22 Sep, 19:04	23 Sep, 07:00	—	Open (overdue)
Store cupboard 3	Lost	Officer Chan	20 Sep, 09:10	20 Sep, 17:00	—	Lost (fine issued, receipt 0142)

Copy these columns into a printable or Excel sheet and it will do the job on a small, single-site board. The moment keys move across shifts or sites – or you need an overdue key flagged automatically and a lost key tied to a recorded fine – a static sheet stops keeping up, which is where a system that stamps and locks each row earns its place.

FAQ

What is a key sign out sheet?
It is a log that records who took a key, when they took it, when it is due back, and when it was returned. It exists to fix responsibility for shared keys and to create a record you can rely on if a key is lost.

What columns should a key sign out sheet have?
At minimum: key identifier, availability status, who took it, accepted date and time, who returned it, expected return, a loss trail for keys that do not come back, and a status column. Missing the return and status columns is the most common reason a key sheet fails.

Is an Excel or PDF key sign out sheet good enough?
A printable or Excel template is fine for a small, single-site setup and it is a good starting point. It breaks down when keys move often, across shifts or sites, because a spreadsheet cannot flag an overdue key, cannot tie a loss to a recorded fine, and can be edited after the fact. At that point a system that stamps and locks each entry is worth the switch.

How does AVES handle a lost key?
The key control workflow records a lost date against the entry, then a fine amount, the person issuing the fine and a receipt number, so the loss is documented and closed. Sign-off throughout is a recorded accept or submit action rather than a signature image.

---

See the key trail on the real screen. Book a 30-minute AVES demo and we will walk you through how a key is requested, issued, returned and, if lost, fined and closed, with the actual guard-app screens, not a mock-up. Book a demo or start a free trial.

Related reading: Key Control · Key Control Software · Shift Handover Checklist. Follow AVES on Instagram.

A visitor sign in sheet is the printable template that sits at your front desk: the single page a visitor completes on arrival, capturing who they are, who they are here to see, and when they came and went. It is the input at the point of entry, the thing a receptionist hands across the counter. This guide is about that sheet as a document: the columns your template must have before you print it, not the running record it eventually feeds.

Most sign in sheets fail for the same reason: the printed template is missing the columns that matter, so every entry has gaps exactly where you later need proof. Below are the seven columns every visitor sign in sheet template should carry, the front-desk mistakes that make one worthless, and where a paper sheet stops being enough. For the ongoing record those sheets build up into, see the AVES visitor log book guide.

Why a visitor sign in sheet matters

The sheet does more than log names. In an evacuation it is the roll call that tells a fire marshal how many non-staff are in the building. In a security review it is how you tie a person to a time and a host. After an incident it is the record that answers the only question that matters: who was here.

The weakness of the paper sheet is that it depends on the visitor filling it in honestly and completely, and on nobody being able to read what the person above them wrote. A sheet left unattended on a counter is not a control at all. That is the problem the right columns, and a digital format, are there to fix.

The 7 columns every visitor sign in sheet needs

1. Visitor name – full name, so the entry is attributable.
2. Company or affiliation – who the visitor represents.
3. Host – the member of staff responsible for the visitor while on site.
4. Purpose of visit – meeting, delivery, contractor work, interview.
5. Time in – the arrival time, recorded at entry.
6. Time out – the departure time, recorded when the visitor leaves. This is the column paper sheets lose most often, and the one an evacuation depends on.
7. Pass or badge number – ties the visitor to the physical or digital pass they were issued.

Higher-security sites add two more: a photo of the visitor and a scan of a photo ID, so the person at the desk can match the badge to the face. AVES issues each visitor pass with an approval step, a QR code and an id or profile photo, so the entry is tied to a verified identity rather than a name written by hand.

Paper sign in sheet versus a digital one

A paper template works until the moment it matters. The recurring failures are always the same: the time-out column left blank, handwriting no one can read, a visitor who signed in as someone they are not, a page that has gone missing. None of these is visible until you need the record and find it incomplete.

A digital sign in sheet captures the same seven columns as structured data. Required fields cannot be skipped, entries are legible because they are typed or selected, and the departure is recorded when the pass is scanned or returned rather than relying on the visitor to sign out. The record is searchable, so you can pull every visit by a contractor or everyone on site on a given afternoon in seconds. For the full workflow around passes, approvals and access, see the AVES visitor management system. To understand why unreturned passes are a risk worth tracking, see visitor pass tracking.

Common visitor sign in sheet mistakes

No sign-out. The single most common gap. Without a time out you cannot prove when someone left or run an accurate evacuation count.

An unattended clipboard. A sheet on the counter with no one checking it lets anyone write anything, or nothing.

No host column. If no staff member is named, no one is accountable for where the visitor goes.

No identity check. A name with nothing behind it is trivial to fake.

Keeping old sheets on display. A completed sheet shows every prior visitor’s details to the next person who signs in. That is a privacy failure. Records should be stored securely, not left face-up on the desk.

Visitor sign in sheet checklist

• Every entry has a name, company and named host.
• Purpose of visit is recorded.
• Both time in and time out are captured.
• A pass or badge number ties the person to a pass.
• Higher-risk sites add a photo and ID check.
• The sheet is controlled by a person, not left unattended.
• Prior entries are not visible to the next visitor.
• Records are stored securely and retained only as long as needed.

Frequently asked questions

What is a visitor sign in sheet?

A visitor sign in sheet is a record kept at a site entrance of every non-staff visitor, capturing their name, host, purpose and their time in and out. It supports evacuation roll calls, security accountability and compliance.

What columns should a visitor sign in sheet have?

Name, company, host, purpose of visit, time in, time out and pass number. Higher-security sites also add a photo and an ID check.

What is the difference between a visitor sign in sheet and a visitor log book?

They are different stages of the same process. A sign in sheet is the printable template a visitor fills in at the desk, one page at a time. A visitor log book is the ongoing record those sheets accumulate into, kept for roll-call and retention. This guide covers the sheet; the log book guide covers the record.

Is a paper visitor sign in sheet GDPR-safe?

A paper sheet that displays previous visitors’ details to the next person signing in is a privacy risk. A digital sheet keeps each entry private and lets you retain and dispose of records securely.

How do you stop people signing in as someone else?

Control the sheet at the desk rather than leaving it out, and add an identity check. A digital pass with a photo and an approval step ties each entry to a verified person.

Move your sign in sheet off the clipboard

If your entrance still runs on a paper sheet, the gaps are only a matter of time. AVES issues every visitor a pass with an approval step, a QR code and a profile photo, and records each visit as a private, searchable entry with the time out captured automatically.

Book a 30-minute demo and we will show you the actual visitor pass and approval screens: Book a demo.

Prefer to explore first? Start a free account.

Follow AVES on Instagram.

A shift change request form is how a guard asks to swap, drop or move a shift, and how a manager approves or rejects that change on the record. It sounds like a small piece of admin. In practice it is the difference between a roster you can trust and a roster where a post quietly goes uncovered because two people agreed a swap in a WhatsApp message no supervisor ever saw.

Most shift change request form entries fail for the same reason a paper visitor sheet fails: the request is verbal or informal, so there is no record of who agreed to what, and no approval step to confirm the site is still covered. This guide sets out the seven fields every shift change request form should capture, and why a digital request beats a paper slip or a text message.

Why a shift change request form matters

Security rosters are coverage promises. A client pays for a post to be manned from a set time to a set time, and the roster is how you keep that promise. The moment a guard cannot make a shift, that promise is at risk, and the shift change request form is the control that protects it.

A good shift change request form does three things. It captures the request in writing so there is no dispute later about who asked for what. It forces the swap to name a replacement, so a change never leaves a gap. And it routes the request to a manager for approval, so no change goes live until someone accountable has confirmed the post is still covered.

Without a form, changes happen in the gaps: a guard tells a colleague they will cover, the colleague forgets, and the first anyone hears of it is an empty post at 2am. The form exists to stop that conversation ever being informal.

The 7 fields every shift change request form needs

1. Requesting employee – the guard asking for the change, so the request is attributable.
2. Original shift – the date, time and site or post the guard is currently rostered for.
3. Type of change – a swap with a named colleague, a drop, or a move to a different date or time.
4. Replacement or cover – who will work the shift instead. A swap request that names no replacement is not a plan, it is a gap.
5. Reason – why the change is needed. This lets a manager judge the request and spot patterns, such as one guard repeatedly avoiding night shifts.
6. Date submitted – when the request was made, so late requests can be distinguished from those raised with proper notice.
7. Manager decision – approved or rejected, by whom, with the date and time. This is the field that turns a request into an authorised change.

Keep the form to these fields and it stays quick to complete, which matters because a form guards will not fill in is no better than no form at all.

Paper shift change slip versus a digital shift change request form

A paper slip or a group chat works right up to the moment it matters. The recurring failures are always the same: a swap agreed verbally that one party forgets, a slip that never reaches the supervisor, a change approved by someone with no authority to approve it, or a request lost so completely that no one can say whether it was ever agreed.

A digital shift change request form captures the same seven fields as structured data and routes it for approval automatically. In AVES, shift change requests are raised by staff and sent to a manager for approval, so a change is only live once it has been authorised, not the moment two guards shake hands on it. Because the request sits against the roster, an approved swap updates the schedule the whole team is working from rather than living in one person’s memory.

The roster it updates is generated and managed in the same system. For how the underlying schedule is built, see the AVES security guard duty roster. For what the guard coming on shift should confirm at handover once a change has gone through, see the shift handover checklist. And because a swap only counts once the replacement actually turns up, geofenced attendance is what confirms the covering guard was on site.

Common shift change request form mistakes

No named replacement. A request to drop a shift without saying who covers it is not a swap, it is a hole in the roster waiting to be found.

Verbal-only agreements. A swap agreed in a corridor or a chat leaves no record. When the post is missed, there is nothing to show what was agreed or by whom.

No approval step. If a change goes live the moment two guards agree, no manager has confirmed the site is still covered or that the replacement is qualified for that post.

Approval by the wrong person. A colleague saying “fine by me” is not authorisation. The decision field must record a manager, not a peer.

Late requests treated the same as planned ones. Without a submission date you cannot tell a request raised a week ahead from one raised an hour before the shift. The reason and date fields let you manage notice periods fairly.

Shift change request form checklist

• The requesting guard and their original shift are named.
• The type of change is clear: swap, drop or move.
• A replacement is named for every swap or drop.
• A reason is recorded.
• The submission date is captured.
• A manager, not a peer, approves or rejects the request.
• The decision, the approver and the date and time are all recorded.
• An approved change updates the roster the whole team works from.

Frequently asked questions

What is a shift change request form?

A shift change request form is a record of a guard’s request to swap, drop or move a rostered shift, capturing the original shift, the replacement, the reason and a manager’s approval. It keeps roster changes authorised and on the record rather than informal.

What should a shift change request form include?

The requesting employee, their original shift, the type of change, the named replacement or cover, the reason, the date submitted and the manager’s decision with the date and time.

What is the difference between a shift swap and a shift change request?

A shift swap is one type of change, where two people exchange shifts. A shift change request is the broader form that also covers dropping a shift or moving it to a different time, each still needing a named replacement and manager approval.

Why does a shift change need manager approval?

Because only a manager can confirm the post is still covered and the replacement is qualified for it. Without an approval step, a change agreed between two guards can leave a site uncovered or manned by someone not cleared for that post.

Can a shift change request be handled digitally?

Yes. A digital shift change request form captures the same fields, routes the request to a manager automatically and updates the shared roster once approved, which removes the verbal agreements and lost slips that paper processes rely on.

Take shift changes off the group chat

If your shift swaps still happen in a group chat, the missed post is only a matter of time. AVES lets a guard raise a shift change request that names the replacement and routes to a manager for approval, so no change goes live until the coverage is confirmed and the roster is updated for everyone.

Book a 30-minute demo and we will show you the actual shift change request and approval screens: Book a demo

Prefer to explore first? Start a free account: Start a free account

Follow AVES on Instagram: Instagram