Mobile app for a private security company: where the duty team's work breaks down
A duty team's shift usually lives on paper: a post log, a report at the end of the shift, patrols — signed in a sheet.
And an alarm signal from a site goes along the chain "client — duty officer — duty team phone," and already on the second call no one can say for sure which guard is closer to the point and available.
Hence three typical failures. An alarm received by voice is lost — it is impossible to reconstruct reaction time and route. A patrol marked with a signature is disputable: the site client asks for evidence, and there is nothing to present.
Security shift accounting is reconciled manually — timesheets, schedules, and route sheets are spread across different files, and discrepancies surface only during calculation.
The cost of each failure is hours of incident investigation, damaged relations with the site, and lost shifts on reconciliation.
A mobile app for a private security company closes this at the level of the duty team's tool: a geotag and photo on every patrol, a panic button instead of a call, an electronic report that immediately goes into 1С along with the rest of HR records.
Monitoring of guard work stops depending on who filled out the paper and how.
Next we break down what such a tool consists of: how an alarm signal from a site is organized, what the dispatcher sees on the map, and how an app for a security company connects with the shift schedule and site cards.
Measurable effect: duty team reaction, reporting, discipline
The key implementation metric is the time from alarm triggering to its confirmation by the duty team.
The task arrives on the device with coordinates, the site card, and the shift supervisor's contact; the duty team confirms acceptance with one button, and the dispatcher sees the status on the map.
The chain "call — clarification — transfer" disappears: confirmation fits into tens of seconds instead of minutes, and this is visible in the log for every dispatch.
Post patrol monitoring is built on tags along the route: scanning records the point, time, and performer, and any deviation from the schedule immediately goes into the report.
The share of confirmed patrols stops being a verbal estimate — for each post you can see how many rounds were completed in full, where points were missed, and at what time.
Security company reporting is assembled automatically: events, patrols, alarms, and photo evidence are uploaded to the accounting system — in our case, integration with 1С.
Manual entry is reduced to handling exceptions rather than transferring shift logs, so closing a shift takes minutes.
Shift discipline changes due to tying every action to an employee and time. A whole class of violations is removed — "forgot to mark," "did not hand over the shift," "reported the alarm late": the system either records the fact or shows its absence. Disputed situations are investigated using the log, not memory.
Comparison of approaches: boxed solution, app builder, or custom build
A "boxed" industry solution covers the basic framework of a security company: requests, shift schedule, incident notifications.
Launch is fast, but the vendor defines the scenarios — route patrols with photo evidence of checkpoints or targeted alarm transmission to a specific duty team cannot be built into it. An app builder removes some limitations but runs into platform constraints.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made solution for a private security company | Typical processes: shifts, requests, reports; launch needed urgently | Patrol and alarm logic is vendor-defined; exchange with the accounting system and monitoring station is only via exports |
| App builder | You need your own interface and a start without a development team | Weak offline mode, scheduled background geolocation; complex roles and access rights cannot be expressed with blocks |
| Development for two platforms | Non-standard scenarios: routes, panic button, operation without connectivity | Longer at the start; after release, support and regular updates are needed |
Where ready-made solutions run into security specifics
The first barrier is operation without connectivity. At sites with dead basements and underground parking garages, an employee walks a route where there is no network at all, and events must accumulate locally and go to the server when a channel appears.
Ready-made platforms and app builders usually fail in such a write queue or lose some marks, while for security it is precisely those marks that prove the post was patrolled.
The second is access differentiation: the dispatcher, shift supervisor, and site owner see different data, and this is built into the role scheme, not into screen settings.
The choice of development approach here comes down to one question: do your routes, alarms, and reporting fit a template — or will the scenario have to be designed specifically for you?
Implementation stages: from shift audit to duty handover
Implementation of an app for a security company starts not with code but with an analysis of how the shift currently lives.
An audit of security processes shows exactly where information breaks: patrols are marked on paper, alarms are reported by voice over radio, and actual time at the post is reconstructed from memory. Until these gaps are described, any app will remain just another log that no one fills in.
- Shift and route audit. We analyze the daily schedule, patrol points, the procedure for taking over and handing over a post, and communication channels with the monitoring station. We record which events are currently not documented and how much time reporting takes.
- Designing duty team workflows. We describe shift takeover, patrol by checkpoints, alarm response, and duty handover. For each scenario, we separately discuss behavior without network — a guard must not depend on coverage at the site.
- Build and configuration for sites. Roles and rights, assigning employees to posts, route map, notifications to the duty officer. Scenarios are built so that a new site is connected by configuration, not by modification.
- Pilot operation. We launch on one or two shifts of a real site and compare patrol marks with actual reports. Discrepancies in route geometry and in triggers are corrected before acceptance, not after.
- Acceptance using a failure checklist. We check what most often breaks in the field: loss of connectivity, discharged phone, synchronization failure, guard change in the middle of the day. Every scenario must be closed without data loss.
- Guard training and handover. Short shift instructions, review of common errors, a separate procedure for shift supervisors. We hand over regulations, administrator access, and the procedure for route changes.
After handover, your side does not depend on us in daily work: routes, employees, and notification rules are changed inside the system. Describe the task — we will come back with an estimate and a stage-by-stage plan.
Handover of the app to the customer: builds, access, regulations
Project handover to the customer is not "handed over the source code and said goodbye," but a package by which the security service works independently.
We record the state of the code, assemble signed versions for both platforms, set up access, and attach regulations: from post patrols to alarm escalation. Below is exactly what the customer keeps.
- Assembled versions — release builds for iOS and Android, the procedure for releasing an update and rolling back to the previous version.
- Route schemes — post patrols, checkpoints, binding to floor plans; the shift supervisor edits the scheme from the control panel.
- Role matrix and access policies — what is available to a guard, shift supervisor, dispatcher, and manager; account blocking rules.
- Post patrol regulations — the procedure for marks at a point, permissible time deviations, response to a missed or falsified mark.
- App documentation — architecture diagram, data composition, integrations with the site's accounting system, deployment and recovery procedure.
- Shift instructions — memos for each role: loss of connectivity, discharged device, replacing an employee at a post.
- Ownership of access — the repository, app store accounts, and control panel are registered to the customer; our rights are limited.
Acceptance follows the same list: we launch the build, issue roles, walk the route, and check escalation. Whatever is not confirmed in a live scenario is refined before signing.
Case: duty team reaction time cut threefold
Security company «Барс-Щит» — 60 duty teams, nine cities, a 24/7 dispatch center. The alarm was transmitted by voice: the operator called the duty team, clarified the site, dictated the details, and only then did the group leave.
Confirmation took from four to six minutes, and disputed patrols were closed based on words — there was no way to check whether the guard reached the point.
What changed
We developed an app for the duty team and a dispatcher workstation. The alarm arrives as a push notification with the site card: address, scheme, dispatch history, contact details of the responsible person.
The duty team confirms dispatch with one touch — the dispatcher sees the status on the map without a call. The patrol is built on tags along the route: scanning, photo evidence, recording time and coordinates. A deviation from the schedule surfaces for the operator immediately, not at a shift review.
| Metric | Before implementation | After |
|---|---|---|
| Alarm confirmation by the duty team | 4–6 minutes | ~1.5 minutes |
| Disputed patrols | every fifth shift | one in twenty-five |
| Manually completed reports | all shifts | about one tenth |
| Calls to the dispatcher per day | 70–90 | 20–25 |
The load on the dispatch center was reduced through automatic routing and real-time statuses.
Handwritten reports are almost displaced: patrol data goes into the system along with photos and tags, and a dispute with the site client is resolved using the chronology of events, not the parties' memory.
Hence the reduction in the number of claims — there is nothing to dispute when every point of the route is confirmed.
Next is how such a support framework lives after launch: updates without shift downtime, operation with weak connectivity, and access for new units.
What to do if sites already have another solution?
There is no need to dismantle the existing solution: the monitoring station software remains the master system for sites, devices, and contracts, and the app is integrated alongside as another client.
If the vendor has opened the exchange interface, integration is direct; if closed, we install an intermediate layer that reads exports and queues events. The dispatcher continues to work in the usual way.
Data exchange with the accounting system is event-based: alarm, arming and disarming, duty team arrival, photo from the post, request closure. Each goes with a unique key — a connection break and resend do not create duplicate dispatches. Back into the app come the site card, team composition, and dispatch history.
We start the phased transition with one branch or one shift: we reconcile logs in shadow mode, then connect the rapid response team, and only after that all sites. At each step, the old system remains operational; rollback is done with one switch.
The limitation is usually not in technology but in the vendor's access to data for the monitoring station software.
If it is completely closed, we build the exchange through an intermediate database or scheduled export — the delay is measured in minutes, and the shift does not depend on it.
The shift does not stop at any stage: both systems live in parallel, and the old one is disabled when the logs match and there are no discrepancies for sites and duty teams.
Technical questions asked before start
Before the start, customers raise the same engineering doubts: what happens to the app at a site without stable connectivity, how it connects with the monitoring station, and what will happen if an employee loses the device.
Below are short answers that are worth checking with your technical service before signing the stages.
What happens to the app where there is no connectivity?
Events accumulate in a local log on the device and go to the dispatch center as soon as a channel appears; alarm events are duplicated over a backup channel. The order of events is preserved, and post marks are not lost.
How does this connect with our dispatch center and accounting?
Through event exchange via a software interface, and for a closed system, through an intermediate layer. We configure filters and priorities so that the dispatcher sees alarms, not a stream of marks.
An employee lost the phone — will data leak?
There is no site database on the device: only the employee's session; data is encrypted. Access is revoked remotely, and all actions remain in the log.
Can we launch only one platform first?
Yes. The core and integration layer are shared; the second platform is added as a separate stage — the first will not have to be rewritten.
What happens after launch?
A support line, updates for new operating system versions, failure analysis by metrics, and an agreed incident response procedure.
Other doubts usually concern access, data migration, and roles — describe the task, and we will come back with an estimate and a stage plan.Let's discuss the task and come back with stage estimates
The estimate starts not with a price list but with an analysis of how your shift is organized. To come back with an implementation plan rather than a raft of assumptions, a minimum set of inputs is needed — usually it is gathered in one meeting.
- structure of posts and branches: who is the dispatcher, who is the shift supervisor, how many sites;
- scenarios: assignment to a post, route patrol, recording an emergency, shift handover;
- current accounting: paper logs, spreadsheets, or an existing program;
- connectivity and devices: corporate or personal phones, areas without stable internet;
- roles and access: guard, supervisor, dispatcher, manager — who sees what;
- data exchange: accounting system, HR, access control — if synchronization is needed;
- constraints: deadlines and testing procedure on your side.
Then the procedure is: we break down the shift step by step, show the solution scheme, and estimate the scope of work by stages. We agree on the implementation plan before the start — with a test environment for the duty shift.
Describe the task — we will come back with stage estimates and a clear work plan.