How many requirements should a visitor management system requirements list have?

Around twenty genuine must-haves and as many nice-to-haves as you like. The common mistake is a list of ninety mandatory lines, which produces one of two outcomes: an inflated quote covering everything, or a vendor answering yes ninety times because no individual line is worth arguing about. Neither helps you choose. Being ruthless about the must-have category is what makes the list useful, because a vendor who cannot meet six of your twenty has told you something clear. Send the list before the demo and ask for written answers against each line, since a written answer is a commitment while a demo answer is a performance.

Should we write requirements as problems or as features?

As problems, almost always. Write that you need to know who is inside the building during an evacuation. Do not write that you need a specific dashboard widget with a particular layout. The moment you specify the solution you eliminate products that solve the problem differently and possibly better, and you also invite vendors to match your wording rather than your need. The exception is where a technical constraint is genuinely fixed, such as an existing badge printer you must continue using or a specific access control system that has to be integrated with. Those are real constraints and belong in the list explicitly.

What should we ask to see in a demo that vendors will not show voluntarily?

Four things. A visitor being checked out rather than in, because arrival is the pleasant part every demo is built around and exit is where products fail. A contractor whose induction expired yesterday, to see whether the system blocks, warns or ignores it. A live list of everyone currently inside, with the question of how it would be used during an evacuation. And a returnable material pass that was never returned, to see whether the product has any concept of overdue. Products that look identical on a requirements matrix separate within a few minutes on these four scenarios.

Do we need a separate section for contractors?

Yes, and treating it as a subheading under visitors is the single most common structural mistake in these lists. A visitor is a one-off event: they arrive, they are hosted, they leave. A contractor is a recurring person carrying documents that expire, and the expiry date is the thing that actually matters. A system that registers a contractor afresh every morning as though they were a new guest throws away the only fact worth tracking. Keeping the sections separate in your requirements forces vendors to answer the contractor question properly rather than pointing at the visitor flow and saying it works the same way.

What commercial questions belong in the requirements document?

The pricing unit and what happens when you grow. Ask whether you are charged per user, per gate, per location or per visitor volume, and then ask specifically what happens to the bill when you add a second gate, a second site or a night shift. Per-user pricing in particular can create an incentive to share logins, which quietly destroys the audit trail you bought the system for. Also ask about annual commitment, renewal uplift, what implementation and training include, retraining cost in year two when guards have changed, and what it costs to export your data and leave. The last answer is usually fine and occasionally revealing.

Visitor Management System Requirements: A Template

# Visitor Management System Requirements: A Template

Most evaluations go wrong before anyone sees a demo, because nobody wrote the visitor management system requirements down. Three vendors present, all three look capable, and the decision ends up resting on which interface felt nicer on the day.

The visitor management system requirements below are a starting template. Take them, delete what does not apply to your site, add what is missing, and send the result to every vendor before their demo rather than after it. That single change does more for the quality of a decision than any amount of comparison reading.

How to use this visitor management system requirements template

Mark every visitor management system requirements line as must-have, nice-to-have or not applicable. Be ruthless about the first category, because a list where everything is a must-have tells a vendor nothing and tells you less.

Send it out in advance, ask for a written response against each line, and keep the responses. A vendor who answers in writing has committed to something. A vendor who answers in a demo has performed something.

Then run the four scenarios at the end. They are where products that look identical on paper stop looking identical.

Visitors

Hosts can pre-register visitors, letting them complete their own details in advance. Walk-in registration is also available for unplanned arrivals at the gate. The system captures a photograph of each visitor at the point of entry. It also captures identity documents, with control over which types are accepted. Phone numbers are verified to confirm the register holds real, working numbers. Hosts must approve entry, and they are reached through a channel they actually use. Each visitor receives a numbered pass, either printed or digital. Exit recording closes the visit properly once the visitor leaves. Repeat visitors are recognised automatically, without re-entering all their details again. A watchlist applies across every entrance, not just the main reception.

Contractors

Treat this as a separate section rather than a subheading under visitors, because the difference is the point.

Contractors registered once, as recurring people, with their firm recorded
Documents with expiry dates: induction, licence, insurance, medical clearance
Validity checked automatically at entry
Expired documents block entry rather than warning
Overrides possible, but recorded against a named person with a reason
Contractor hours derived from entry and exit records

Material and vehicles

Skip this section entirely if nothing leaves your site. For industrial sites, safety and inspectorate material published by DGFASLI is a useful cross-check on what your gate records need to support. If anything does, it is often half your gate traffic and most products handle it badly.

Inward and outward material passes
Returnable movement, with an expected return date and visibility of what is overdue
Authorisation recorded before material leaves
Vehicle number captured against the movement
Courier and parcel logging

Multiple gates and sites

One policy applied across every gate
Visitors entering at one gate and exiting at another handled correctly
Per-gate reporting as well as consolidated
New sites added without a fresh implementation project

Records and reporting

Search by name, date, gate, host, company or vehicle
Export to CSV
Live occupancy: who is inside right now
Roll-call list usable during an evacuation
An audit log of user actions, not only visitor actions
Report generation without vendor involvement

Data protection

Role-based access, so a guard sees only what a guard needs
Permanent deletion, not hiding or flagging
Photographs and document images deleted along with the record
Retention periods that can be set and enforced
Clarity on where data is hosted

Be careful with any vendor who describes their product as making you compliant with India's DPDP Act. The Act and the rules made under it are published by MEITY, and reading the source is quicker than most vendor explanations of it. Your organisation is the Data Fiduciary and those duties do not transfer to a supplier. We set out what that means in practice on the DPDP and visitor data page.

Hardware and access

What is the minimum required to go live at one gate
Whether it runs on phones and tablets you already own
Whether a kiosk is required or optional
Which badge printers are supported, including any you already have
Behaviour when the internet drops at the gate
Integration with turnstiles or barriers, if that is genuinely a requirement

Support and commercial

Support hours, channels, and what the standard tier includes
Whether raising a ticket is built into the product
Training at go-live, and retraining cost in year two when guards have changed
The pricing unit: per user, per gate, per location or per visitor volume
What happens to the cost when a second gate or a night shift is added
Annual commitment and renewal uplift
Cost to export your data and leave

That last line is worth keeping even though it feels pessimistic. The answer is usually fine, and a product that charges you to leave has told you something useful early.

The four scenarios

Written visitor management system requirements get you a shortlist. These get you a decision. In every demo, decline the prepared flow and ask to see:

A visitor being checked out. Not in. Almost every demo shows arrival, because arrival is the pleasant part. Exit is where products and paper both fail, and it is what makes occupancy mean anything.

A contractor whose induction expired yesterday. Watch what the system does. A block, a warning, or nothing at all tells you more than the entire feature list.

A live list of everyone inside, timed. Ask how it would be used during an evacuation. If the answer involves exporting a report, it is not a roll-call.

A returnable material pass that was never returned. Ask how the site would know. Many products have no concept of overdue.

Products that appear identical on a requirements matrix separate within minutes on these four.

What to leave out

Two temptations to resist when writing visitor management system requirements.

The first is asking for everything. A list of ninety must-haves gets you either an inflated quote or a vendor telling you yes ninety times. Twenty real must-haves get you a usable comparison.

The second is specifying the solution rather than the requirement. Write down that you need to know who is inside during an evacuation. Do not write down that you need a specific dashboard widget, because you have then eliminated products that solve the problem a different and possibly better way.

If you want the reasoning behind these visitor management system requirements rather than the list itself, the buyer's guide covers how the categories of product differ and which questions matter at each stage. Our own pricing is published, which makes the commercial section above easy to test on us first.