On this page9 sections
Key takeaways
- An exception breaks an expected pattern, invites an action and loses value if it waits.
- Keep three triage tiers, and give every state, shift and escalation a named owning role.
- Require a reason for every dismissal; those reasons are what you tune against.
- Software observes, groups and routes. People decide, and escalate through your own procedures.
A camera-based system notices far more than any team can act on. Vehicles arrive, move between rows, leave for test drives and come back; porters and customers walk the lot at every hour. Almost all of it is the ordinary rhythm of a site, and it belongs in a log, not in someone’s notifications.
Exception review is the work of deciding which small share of events deserves a person’s attention, getting each one to the right person and recording what they decided. This guide covers how to design that workflow before any alerts are switched on. One principle sits under every section: software can observe, group and route, but people decide what an observation means and what to do about it.
Exception or routine event?
Start by writing down what routine looks like at your site, because an exception only makes sense against a baseline. A vehicle entering the service drive during business hours is routine. The same movement at night, in a zone that closed hours ago, is not. A practical test: an event is an exception when all three of these hold.
- It departs from an expected pattern for that place and time.
- Someone could reasonably act on it, even if only to look and confirm.
- Waiting for the next routine report would make that action less useful.
An event that fails the second test is information for a daily summary. One that fails the third belongs in a daytime queue, not on a phone. Because so much depends on place, well-defined zones come first; mapping a vehicle lot covers how to draw them.
Typical dealership exceptions include movement in a closed zone after hours, a vehicle leaving without a matching test drive or delivery record, and a vehicle missing from its assigned area. For commercial parking: a zone filling sooner than the overflow plan assumes, a blocked fire lane or loading bay, a vehicle long overstaying a short-stay area. Add one more to every list: a camera that has stopped reporting. Silence from the system is an exception in its own right.
Three triage tiers
Tiers express urgency, not importance. Keep to three; beyond that, people stop remembering what each one means.
- Act now. A person should look within minutes: activity in a closed zone, a vehicle leaving outside hours, a blocked emergency route. Routed to a named person on shift, with a fallback if nobody acknowledges it.
- Act today. Needs attention before the shift ends: a vehicle missing from its row, a test drive running long. Queued for the responsible role, without a push notification.
- Review later. Patterns and housekeeping: repeated visits to one corner of the lot, a camera view partly blocked by a parked truck. Collected for the weekly review.
Assign tiers per exception type, zone and time window: the same event can be “act now” at night and “act today” during staffed hours. If you cannot write a pairing as one sentence, the definition is not finished.
A tier is a promise about response, not a label. If “act now” items routinely sit unacknowledged, either the tier or the staffing is wrong.
Ownership by role and shift
Every exception type needs an owning role for every hour of the week. Use roles rather than names (lot porter lead, service manager, night security contractor) and keep a separate roster mapping roles to people per shift, so leave changes the roster, not the rules.
Watch three recurring gaps. At shift handover, open items should carry their owner across with a note rather than drop back into a shared pool. On weekends and holidays, the backup must know they are the backup. For cross-department items, such as a vehicle that might be in service, on a test drive or already sold, decide which role investigates first.
A RACI view of the workflow
A responsibility table makes the design explicit. Adapt the role names to your organization.
| Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Define exception types and tiers | Operations manager | Site lead | Security lead, IT | Shift leads |
| Acknowledge and assess an “act now” item | On-shift owner | Shift lead | Security contractor | Operations manager |
| Decide whether to involve security or emergency services | Shift lead or on-call manager | Site lead | Security contractor | Operations manager |
| Resolve or dismiss with a note | Assigned owner | Shift lead | Colleagues involved | Weekly review |
| Tune rules and suppression windows | Operations manager | Site lead | IT, security lead | Shift leads |
| Run the weekly review | Operations manager | Site lead | Shift leads, security lead | Leadership |
Each row has exactly one accountable role. Above all, name in advance who decides to involve an outside security company or emergency services; do not discover it at the moment it matters.
Response states, and an owner for each
States make work visible. A small, fixed set is enough.
| State | Meaning | Owned by |
|---|---|---|
| New | Raised and routed; nobody has looked yet | The role routed for that tier and shift |
| Acknowledged | A person has seen it and is assessing | The person now assessing it |
| Assigned | Handed to a specific person to act on | The assignee |
| Escalated | Passed up or out because it exceeds the owner’s authority or capacity | The named recipient, once they accept it |
| Resolved | Action taken and the outcome recorded | Closed by the owner, with a note |
| Dismissed | Reviewed and judged not to need action | Closed by the owner, with a reason |
Items without an owner are where review processes fail quietly. “New” belongs to whoever it was routed to, not to “the team”. “Escalated” is the riskiest state: the sender feels the matter is handled while the recipient may not know it exists. Treat escalation as a handoff that must itself be acknowledged.
Dismissed deserves the same respect as resolved. A dismissal with a reason (“porters moving trade-ins for the morning detail, confirmed by radio”) is evidence you can tune against; one without a reason is noise layered on noise. Make the reason required, with common reasons offered alongside free text.
After-hours routing and on-call
Nights and weekends mean fewer people, longer distances and more at stake when an item is missed. Design them as their own schedule, not as daytime rules with fewer recipients.
- Name the on-call role and its backup. An unacknowledged “act now” item moves to the backup, then to a manager, on windows agreed with the people who carry the phone.
- Decide what reaches a phone. Only “act now” items. Everything else waits, sorted, for the morning shift.
- Keep observation and response separate. The on-call person reviews what was observed and decides what happens next, contacting any monitoring or patrol service through your existing procedures.
- Plan for the quiet failure. A lost connection or an offline camera reaches the on-call role too, so silence is never mistaken for calm.
- Hand over in the morning. A short summary: what came in, what was done, what remains open and who owns it now.
Notes and the audit trail
The audit trail is how a team remembers. For any exception it should show what was observed, who saw it, what they decided and why, and what happened next.
Write notes for a reader who arrives weeks later with no context. Good notes are short and factual: “Checked the camera view. Two porters moving vehicles to row F for detailing. Confirmed with the shift lead. Dismissed.”
- Record state changes automatically, with time and person. Ask people only for the judgment.
- Never edit or delete a past note. Add a correction as a new entry.
- Link related exceptions so a pattern reads as one story.
- Agree on how long records are kept and who can see or export them. Those choices are made per site; make them deliberately and write them down.
Reducing noise
Alert fatigue is the most common way a review workflow breaks. Once people learn that most notifications are irrelevant, they ignore all of them, including the ones that matter. Treat noise as a defect to fix.
Tune at the source
Adjust zone boundaries, schedules and thresholds so known routine activity never qualifies. If the detail crew works row F every morning, that schedule belongs in the rules, not in a stream of dismissals. And when the same dismissal reason keeps appearing against one rule, change the rule.
Use suppression windows deliberately
A suppression window silences one exception type in one zone for a defined period, such as a lot sweep or a transporter unloading. Every window needs an owner, a reason and an end time; open-ended suppression is how real exceptions go unseen.
Group related events
A burst of movement in one zone within a few minutes is one situation, not many. Grouping by zone and time gives the reviewer a single item with the full sequence attached: quieter, and easier to judge.
Sample playbook: activity in a closed zone after hours
A playbook turns a design into something a person can follow at an inconvenient hour. Keep each to a single screen, and adapt the roles and contacts to your site.
- Trigger
- Person or vehicle movement in a zone marked closed, outside its scheduled hours
- Tier
- Act now
- Routed to
- On-call lot manager, then the backup after the agreed acknowledgement window, then the site lead
- Acknowledge. Take ownership so the backup is not paged unnecessarily.
- Look before acting. Review the event, the zone’s recent activity and any camera view your site makes available, then check the schedule for an expected delivery, sweep or maintenance visit.
- Look for a known explanation. Call any scheduled crew or night staff. If the activity is explained, dismiss with the reason.
- Decide on escalation. If the activity is unexplained and concerning, follow your site’s procedure: contact your security provider or, where people or property are at risk, emergency services. That decision and that call belong to the person on call.
- Record what you did. Note each action and who you spoke to. Set the state to escalated, naming the recipient, until the outcome is known.
- Close the loop. Once the situation is over, resolve it with a short summary and flag anything for the weekly review: a camera angle that hid the activity, a schedule nobody shared, a gate left open.
The software’s role ends at observing, organizing and routing. It does not dispatch guards, contact authorities, lock gates or take enforcement action. Those are human decisions under your site’s procedures; say so in every playbook so nobody waits for the system to act.
Reviewing the review process
Hold a short weekly meeting with the operations manager, a shift lead and whoever represents security. Work through the same agenda every time:
- Which “act now” items were acknowledged late, and which items sat in “new” or “escalated” without movement?
- Which rules produced the most dismissals, and what reasons were given?
- Did anything happen that the workflow should have caught and did not?
- Is every suppression window still justified, and does each have an end time?
- Do the roster and on-call schedule match who actually worked?
Make one or two changes a week, record what changed and why, and check the effect next time. Small, recorded adjustments keep the workflow trustworthy.
ParkSense is built around this workflow: it turns lot activity into structured events, routes exceptions by zone and role, and keeps state history and notes with each item, while decisions stay with your team. Try the review actions in the interactive product tour, see how they fit dealership lot operations, or talk with us about your own exception types.