Define the work the software must support
Choose access-control software by testing the tasks your staff must perform: approving access, issuing credentials, setting schedules, removing former users, investigating door events and recovering from faults. A feature list is useful only when it describes the proposed controllers, readers, software version and licenses.
Start with a door inventory and an approved permission matrix. List each user group, permitted doors, operating hours, temporary exceptions and the person responsible for approval. Separate daily administration from system configuration and service access.
Test everyday administration
Give the demonstration operator a written scenario rather than asking for a general tour. Have a staff member follow the workflow without vendor coaching, then record the time, unclear steps and permissions required.
- Add an employee with access to two doors during a defined shift.
- Issue a contractor credential with an expiry date.
- Revoke a lost credential and show how the change reaches the affected controllers.
- Change a holiday schedule without changing ordinary weekly hours.
- Give a local manager authority over one building without granting access to other sites.
- Locate the audit record for an administrator’s permission change.
For expansion, request the supported limits for doors, controllers, users, sites and concurrent administrators. Record the extra licenses, hardware or server work needed at the next expected growth stage.
Verify each proposed integration
For video, intrusion, intercoms and identity systems, name the exact products and the action expected. An available API or compatible brand name does not establish that the requested workflow is included.
Ask for a demonstration using the proposed versions. Specify who maintains the connection, which account permissions it needs, what events pass between systems and how a failed connection becomes visible to an operator. Include integration licenses and support responsibility in the proposal.
Make alarms and reports actionable
For a forced-door or held-open event, define the recipient, response procedure, acknowledgement and escalation. Establish who handles alarms outside normal hours. A notification that nobody owns is an incomplete operating procedure.
Request a sample report with recognizable door names, timestamps, credential identifiers and event descriptions. Check filtering and export using a realistic incident. Treat credential activity as evidence that a credential was presented; investigate who actually entered using the other evidence available.
Compare operating responsibilities
| Question | Evidence to request |
|---|---|
| Where is management hosted? | Hosting arrangement, account ownership, recurring charges and support contacts. |
| What continues during an outage? | Written behavior for controller, server, network and internet failures; permission updates, event storage and recovery. |
| Who maintains the system? | Responsibility for updates, backups, certificates, remote access and compatibility testing. |
| How can the owner leave? | Export formats, credential and hardware limitations, contract terms and administrator handover. |
Compare cloud, on-premises and hybrid proposals against these same questions. Ask the provider to distinguish tested behavior from assumptions about the product family.
Document ownership and sensitive information
Identify the owner of user records, access approvals and administrator accounts. Define what information will be stored, who may view or export it and how long it should be retained. Include the process for correcting records and removing users.
Where a project has specific privacy, contractual or regulatory obligations, provide those requirements to the responsible reviewers. Ask for evidence against each requirement. Buying software does not by itself establish compliance.
Document the approved door sequence separately from the software demonstration. Questions about emergency release, fire interfaces or required egress belong with the qualified project team and responsible authority; do not assume that an emergency requires every door to unlock.
Compare the full operating cost
Request separate figures for equipment, software, installation, migration, training, integrations and recurring services. Identify charges for additional doors, credentials, mobile access, reporting, technical support, hosting and software updates.
Use the same door count, user count and evaluation period for every proposal. Record renewal terms and exclusions. A lower starting price may reflect fewer functions or more work assigned to your staff; make those differences explicit.
Use a demonstration scorecard
| Requirement | Result to record |
|---|---|
| Routine administrator tasks | Pass, limitation or not demonstrated; operator notes. |
| Existing equipment reuse | Exact models, compatibility evidence and required changes. |
| Outage and recovery | Proposed behavior, test method and responsible witness. |
| Integration | Versions, licenses, data exchanged and failure handling. |
| Support | Support hours, escalation route, remote access process and exclusions. |
| Owner handover | Accounts, licenses, configuration records, exports and training. |
Include door hardware support in the evaluation. A software event cannot establish that a door closes, latches or releases correctly. State who investigates mechanical, electrical, network and software faults, including issues that cross those boundaries.
Plan migration and acceptance
Clean the user list before importing it. Obtain approval for the intended permissions and schedules; do not carry obsolete access forward simply because it exists in an old database. Agree on the cutover window, temporary arrangements, rollback conditions and the person authorized to accept the result.
Train the actual administrators using their normal tasks. Record acceptance results by door and workflow, identify unresolved items and assign an owner and due date. Coordinate disruptive tests with the people responsible for the building and connected systems.
Maintain a usable system record
Keep the approved permission matrix, door names, administrator list, configuration records, license details and support contacts current. Define a review schedule and revisit it after staffing, tenancy, equipment or operating-hour changes.
Continue with the software architecture guide for management responsibilities and the commissioning and maintenance checklist for handover records.
Publisher’s related applied reference: commercial access-control system application.