Visitor planning
Best Visitor Management Software: Check the Exit Plan Before You Buy
The best visitor management software for your project needs a workable exit plan. Test exports, record relationships, active credentials and device handover before choosing a platform or service provider.

Before you choose
Key takeaways.
- Test a usable handover package before buying, including the relationships between records.
- Give historical data, active credentials, administrator access and device configuration separate owners.
- Agree the assistance, access window and acceptance evidence needed when the service ends.
Choose the exit outcome while you can still compare proposals
The best visitor management software for your project should let the organization retrieve the records it needs and hand over the operating arrangement when the supplier relationship ends. Before buying, ask the vendor to demonstrate a sample export, explain which relationships survive it, and name who handles active credentials, administrator accounts and connected devices. A visible Export button leaves those decisions open.
An exit plan covers a change of platform, service provider or contract. It has a different purpose from checking one visitor out at reception. Define the outcome in operational terms: authorized staff can explain retained visits, the replacement team understands the configuration, and the site knows which system still controls live permissions. Use those conditions to judge fit instead of treating Best as a universal ranking.
Separate the records that must leave from the actions that must stop
A handover inventory should distinguish a visitor profile, an appointment, an actual visit, an issued credential and a door event. One person may have several appointments and several visits. A credential may remain valid after a visit ends, depending on the approved project rule. Request the identifiers that connect these objects, rather than relying on a name and date that could match several records.
Administrator accounts belong in a separate operating inventory. Identify reception users, customer administrators, integrator access, supplier support access and application connections. Ask who can authorize each account or connection to stop, and who verifies the result. Historical records do not require every former service account to remain usable.
Decide which information the organization actually needs to keep, who may receive it and where it will be stored. Include the relevant attachments and configuration references in that decision. The project owner should agree retention and handling requirements with the appropriate internal team; a procurement comparison should not invent a universal retention period.
Ask for an export you can interpret without the old dashboard
Choose a sample period containing a repeat visitor, a canceled appointment, an incomplete visit and a visit linked to a credential. Ask the supplier to export that set using the proposed customer permissions. Inspect the fields, date range, location identifiers, time zone, status values and relationship keys. Record the export settings so another authorized person can repeat the exercise.
A CSV can be readable while still lacking the meaning needed by the next system. Ask for a field dictionary and examples of blank values, corrected records and historical changes. Test names with punctuation and identifiers with leading zeros. Confirm whether the export is intended for independent reference, import into another platform, or both; successful import requires a separately agreed receiving specification.
Use the sales demonstration as a handover acceptance test
Give shortlisted suppliers the same small test pack and ask them to return the evidence below. The table is a buyer-defined acceptance framework. Its questions do not imply that every platform includes the listed export objects or that every organization needs them all. Mark exclusions explicitly and identify the party that will resolve them.
| Area | Ask the supplier to demonstrate | Evidence to retain |
|---|---|---|
| Record scope | Export the agreed locations, period and record types, including exceptions. | Export settings, files and an explained record count. |
| Relationships | Follow one person through an appointment, visit and relevant credential or event reference. | Field dictionary and a reconciled example with stable keys. |
| Files and history | Explain attachments, link expiry, corrections and historical limitations. | Usable authorized files and documented exclusions. |
| Live permissions | Show how still-valid test credentials are accounted for at the handover boundary. | Named permission owner and observed test result. |
| Administration | Explain how customer, supplier and integration access will be reviewed and retired. | Account and connection inventory with responsible owners. |
| Devices and assistance | Identify configuration references, required services and handover dependencies. | Matched configuration pack, assistance scope and acceptance sign-off. |
Treat permission closure and device handover as separate work
Exporting a visit log does not establish that a still-valid pass has been disabled. Ask which system owns each credential and which approved action ends its validity. Include any separately managed door platform and the responsible site operator in the plan. Use permitted test credentials to verify the intended result through the actual arrangement, with a controlled exception process for unresolved cases.
Device configuration needs its own handover package: accurate model, interface version, application firmware, mounting and wiring references, host settings and support contact. Agree a controlled method for handling credentials or secrets; ordinary project documents should not contain reusable passwords. Changing a management service does not automatically transfer an application, license or supported protocol.
Rehearse one small exit before committing the whole site
Consider this illustrative procurement exercise: an office is evaluating a replacement visitor service while keeping suitable entrance hardware. The team selects one authorized test visitor with two appointments, one canceled appointment and a pass that remains valid at the planned handover time. The supplier provides the agreed export; the receiving team explains the relationships and reports any missing fields before the site changes service.
Reception checks that staff can answer a historical question using the retained package. IT reviews the accounts and integration connections. The access-system owner checks the test pass under the agreed transition rule. A discrepancy stays in an issues register with an owner and decision deadline. The exercise is a proposed acceptance method, not a report of a Feocey customer project or an automatic migration service.
- Agree the sample, expected relationships and handover time before generating the files.
- Keep the original export unchanged and document any transformation in a separate copy.
- Reconcile records and required files, then test the separately approved permission changes.
- Record unresolved items and the decision authority before extending the change to more locations.
Put assistance and post-contract access into the written scope
Ask whether the customer can perform the required export directly or needs a supplier service, special permission or additional tool. Request the format, preparation time, assistance scope and any applicable charge in writing. A sample download during the sales process does not settle the commercial terms for an organization-wide handover years later.
Confirm when the old dashboard, support service, file links and integration connections cease to be available. Ask how a final export and any later corrections will be handled. Assign who confirms receipt, who signs off the handover and who authorizes subsequent data or account actions. Keep these responsibilities specific to the agreement; do not assume that ending billing performs every technical closure task.
Bring the device boundary into a Feocey project discussion
The FC6820 terminal is available in reader and access-control configurations. The FC7735 reader passes credential data through the selected output to a receiving system that validates it and controls passage. Confirm their actual configuration, firmware and operating role before deciding what can stay during a software change.
Review the FC7735 manual, matching FC6820 documents and hardware integration overview. Send the current platform, equipment list, desired retained hardware and exit-test evidence with your FC7735 project inquiry. Ask Feocey to assess the hardware, integration or wider solution scope against the project. A protocol reference or development option does not establish a universal platform connector, historical-data transfer or automatic rollback.
Source references
FC7735 user manual — match the supplied interface version ↗FC6820 user manual — confirm reader or access-control configuration ↗Put the guide to work
Find the reference for your model.
Compare each device with your requirements. Confirm configuration and compatibility for the complete installation.
FC6820 →
Display QR and card terminal
Ask about FC6820 ↗FC7735 →
86-box QR and card reader
Ask about FC7735 ↗