Website development for a security company: where requests get lost
A typical security company website works like this: a “leave a request” form sends an email to a shared inbox and duplicates the message to a messenger, and after that everything depends on who sees the notification first.
At the same time, a security request gets neither a number, nor a status, nor an owner — and a day later no one can find it. At the moment of contact, the client is choosing a contractor, so a pause of several hours often means the facility has already gone to a competitor.
Lost requests from the website rarely look like an obvious failure. The form works, emails arrive, but some inquiries settle in spam, some in employees’ private chats, and some get lost during shift handover.
The owner sees only the result: there seem to be many inquiries but few contracts, and it is unclear at which step a specific request stalled.
The second half of the picture is record-keeping of facilities and posts. While it lives in spreadsheets, the dispatcher manually reconciles shift schedules, post staffing, and employee contacts.
When a person is replaced or a new facility is connected, the versions diverge: in one spreadsheet the post is covered, in another it is not, and no one has a reliable picture of shifts.
This is also why there are constant calls to the dispatcher: it is easier for the client to clarify the status by voice than to wait for a reply in a chat.
We explain how this loop is closed — from accepting security requests to a single card of the facility, post, and shift, where you can see who took the request into work and when.
What changes after the portal launch: measurable effects
The portal changes not “interface convenience” but the distribution of work between people and the system. Below are four areas where the effect is visible in metrics already in the first months of operation.
Requests without manual entry
The client submits a request in the account area or mobile app, and it is immediately routed by facility, post, and shift. The dispatcher does not retype data from email and messengers — the share of requests processed without manual entry reaches 9 out of 10. The rest are marked as non-standard with the reason indicated, and this is visible in the report.
Response to an alarm message
An alarm from a facility enters a priority queue and pops up for an available operator instead of waiting for a journal review. The event is recorded with a timestamp, and escalation triggers if no one takes it into work within a specified interval. Response time is reduced from minutes to tens of seconds and stops depending on shift workload.
Shift schedule without overlaps
The system checks for overlaps, overtime, and the situation when an employee is assigned to two posts at the same time, and takes into account clearances and guard license expiration dates.
The schedule is synchronized with 1C, so discrepancies between the assignment and records do not accumulate. Errors are caught at the moment of publication, not when the period is closed — their number drops several times over.
The class of failures that goes away
Previously, requests were lost, assignments were duplicated, and discrepancies in hours surfaced. Now every action has an author, a time, and a trace in the log, and disputed cases are resolved based on facts, not memory.
The load on the dispatcher decreases due to automation of security requests, and the shift no longer depends on one experienced person.
Portal formats for a security company: showcase or account area
The portal format is determined not by the size of the company but by who performs actions in the system: the client ordering security or the employee at a post.
The same set of data — contracts, facilities, posts, assignments — is revealed differently, and this determines the scope of work and the launch order.
| Format | When it fits | Limitations |
|---|---|---|
| Security services showcase website | Requests and trust are needed: services, licenses, facilities, security formats; launch in a short time | The request goes to a manager manually — the client has no history of inquiries, statuses, or documents |
| Customer account for the security client | The client has several facilities and regular document flow: certificates, assignment reports, change requests | Needs to be linked to the accounting system and access must be differentiated by facility and role |
| Self-service portal with a security guard mobile app | A full cycle is needed: request, assignment, check-ins at the facility, shift closing | More expensive to develop; requires offline mode at posts, geotags, and procedures for employees |
The formats are compatible and are built up in stages: the showcase gathers demand, the account area relieves the load on managers, and the guard app closes shifts at facilities.
We design the data model and roles for future development from the start — the next module is connected without rewriting what is already done.
Work stages: from process review to portal handover
The order of stages is dictated by the subject: a security company portal is a superstructure over the record-keeping of facilities, posts, shifts, and alarm events.
If you start with interface assembly, the role scheme will have to be redone for the finished screens, and integrations will have to be bolted onto an inconvenient data model.
- Security process audit — interviews with dispatchers, shift supervisors, and facility engineers; we document patrol routes, the alarm response procedure, and the shift closing order. The output is a process map with the points where data is lost or duplicated.
- Role and access scheme — a “role × facility × action” matrix: the dispatcher sees only their own posts, the department head sees a summary for all, and the client of a guarded facility sees request statuses and reports.
- Data model and integrations — facilities, posts, assignments, employees, equipment, alarm events. We determine what the portal reads from the existing system and what it maintains itself, and how conflicts are resolved during simultaneous editing.
- Iterative assembly — every two weeks a working version on the test environment: first reference data and permissions, then assignments and shift schedules, then reports and the mobile part for shift employees.
- Pre-launch testing on a pilot group of facilities: running alarm scenarios, mass shift starts, and expired accesses. We go through each role’s permissions manually — this is how we find holes that automated tests do not catch.
- Training and handover — instructions for each role, integration diagrams, backup and recovery procedures, access handover, and review of typical operator errors.
Documentation, process diagrams, and accesses: what we hand over
A security portal lives longer than the team that built it: dispatchers change, branches are added, and some rules are kept in the administrator’s head and surface only at the moment of failure.
That is why the documentation set is assembled in parallel with the development of the security company website and handed over together with accesses — then onboarding a new employee takes hours, not weeks of correspondence.
- Employee access rights — a “role × section × action” matrix: what the dispatcher sees, what the contractor at the facility is restricted from, which managers export reports, and where the administrator’s zone ends.
- Request processing procedure — the order from signal acceptance to closing: classification, assignment, dispatch confirmation, and recording response time at each step.
- Alarm message procedure — a separate branch with timer-based escalation, contact duplication rules, and mandatory reason marking if the signal is cleared manually.
- Process diagrams — a map of request and alarm routes in clear blocks: you can see where the document gets lost and which step requires approval.
- Dispatcher instructions — short scenarios for each common situation: new facility, canceled dispatch, incorrect address, client complaint.
- Backup procedure — what is saved and how often, where copies are stored, how long recovery takes, and who is responsible for verification.
- Access handover — a list of accounts with owners, the issuance method, and the closure procedure when an employee leaves.
Portal documentation is not handed over “for a checkmark”: during acceptance, your specialists restore a copy and close a request according to the instructions without our prompting. If the scenario does not pass, the procedure is corrected before signing.
Case study: how manual distribution of requests between posts was eliminated
The client is the security company Krepost: several dozen facilities, round-the-clock posts, and mobile crews.
The dispatcher distributed alarms from the control panel manually — call, spreadsheet, radio — and during a shift when signals came simultaneously, distribution turned into a bottleneck.
What it was like before the portal implementation
At night one dispatcher worked: three to four minutes to confirm and call the crew, plus more time to clarify clearance and the shift schedule. Some signals went not to the nearest crew but to whoever answered — and the vehicle drove across the city.
Over a shift, more than two hundred manual operations accumulated, and alarms that hit the peak were lost in the journal.
What was changed and what the result was
The portal was connected to the monitoring station software directly: the signal immediately enters a common queue with address, facility type, and owner tag.
Then the algorithm selects a crew — by distance, availability, clearance for the facility, and shift schedule; the route sheet goes to the patrol officer’s mobile app, and confirmation and status return to the dispatch center.
If the crew does not confirm within the control time, the request is escalated to the next one by priority, and only then does a person get involved.
- share of automatic distributions: 0 → 94%;
- average signal response time: 18 minutes → 4 minutes;
- manual operations per shift: 220 → 30;
- lost requests per quarter: isolated cases → zero, with a full history for every alarm.
Dispatchers moved from distributing requests to monitoring exceptions — disputed addresses, non-standard facilities, and communication failures.
How a portal differs from a website with a request form
A request form is a single write operation. It accepts an inquiry and transfers it to email or a spreadsheet, and after that the state lives in correspondence and calls: who accepted it, for which facility, whether the crew was dispatched. This leads to typical losses — duplicates, forgotten inquiries, and requests without an owner.
A portal starts with a data model, not with a “Submit” button. It includes a security facility: address, mode, post, responsible person, contract.
It includes an employee with clearances and a shift, and the request itself, which references the facility and contract rather than existing separately from them.
A request lives through a lifecycle: new, approval, assignment, in progress, closed. Each transition is recorded with author and time, so you can see not only the current position but also how it came about. Reopening and stepping back do not erase the history — they are separate entries in the log.
Statuses for the client are a separate layer over internal states. The client sees their facilities and their inquiries, the stage in clear language, the scope of work, and attached documents.
For a security company, this removes most of the “what’s happening with the request” calls, and disputed situations are resolved by the log, not by memory.
The boundary is this: a website with a form answers the question “has the inquiry been received?”, while a portal answers the question “what is happening with the facility now and how will the shift end?”.
Therefore, the choice between a portal or a website with a form is a choice between accepting inquiries and managing security.
Technical questions asked before project start
Technical doubts at the start are usually the same: what to do with the existing website, how the portal exchanges data with the accounting system and shift schedule, how to migrate from spreadsheets, and who is responsible for operation after launch.
Below are short answers so that the client and their IT department have one picture before signing the work plan.
We have a website — will it have to be rebuilt from scratch?
First, an audit: we look at the structure, page addresses, content volume, and what already works. We preserve what delivers results — texts, facility cards, search visibility — and transfer it to a new foundation while preserving addresses and redirect rules.
A complete replacement is needed only where the current foundation cannot support the customer account and integrations.
How will the portal connect to the accounting system and shift schedule?
We build the exchange in two directions: requests from the portal go to the accounting system, and statuses, facilities, and the shift schedule come back.
If the system does not expose data directly, we set up an intermediate storage and scheduled exchange — the dispatcher enters the shift once, and the client sees the current schedule in the account area. Discrepancies are resolved by the time of the last record change.
We have kept everything in spreadsheets for years — will you migrate the data?
Yes, we migrate it: export, normalization of facility addresses, phone numbers, and names, duplicate removal, and batch loading with an error log.
Before loading into the production environment, we run everything on the test one and verify control totals for the number of contracts, facilities, and shifts. Re-running the load does not create duplicates, so a failure in the middle does not roll back the work.
Who maintains the portal after launch?
We take support upon ourselves: updates, backups, availability monitoring, maintenance window, and a clear escalation procedure. For the first weeks after launch we pay increased attention — we look at where employees bypass the portal and adjust the interface. We roll out updates so that rolling back to the previous version takes minutes, not a day.
Tell us about your processes — we will come back with a plan and estimate
Portal estimation begins not with a ready-made technical specification but with the materials already in use.
From the process diagram, list of facilities, and roles, the scope is visible: how many entities and scenarios, where manual operations will have to be covered by automation, and which external systems provide data.
With this set, we come back with a work plan and timelines, not with clarifying questions about every detail.
To quickly discuss portal development, send us:
- process diagram — from a request for a facility and post assignment to shift closing and a report to the client;
- list of facilities and posts with types: stationary, response group, control room;
- roles and rights — dispatcher, control room operator, shift supervisor, manager, company client;
- list of systems for data exchange: accounting, client billing, alarm system, HR;
- document samples — shift log, work order, acceptance certificate, facility report;
- restrictions on accesses and data placement, if already defined.
The first review takes about an hour: we go through the processes, note where time is currently lost, and define the boundaries of the first version. Then we prepare an estimate for the portal project — by stages, with dependencies and assumptions.
We provide preliminary timeline figures within two to three business days, and the full work plan and composition of implementation stages within a week.
