Credential projects stall in the gap between a property, a supplier and an integrator, with each waiting for information one of the others holds. The gap closes as soon as somebody writes down who owns which question.
- Who owns what
- The questions to ask in writing
- Where integrators are cautious, and why
- Testing together
- When the integrator is also the credential supplier
Who owns what
The integrator owns the installation: which credential type it is configured to accept, how credentials are encoded, who holds the keys, and what happens when a new credential type is introduced. The credential supplier owns the physical product against that confirmed environment. The property owns the decision and the guest experience.
Almost every stalled project has those three sets confused, usually with the property asking a supplier a question only the integrator can answer.
- Integrator
- Configured credential type, encoding, keys, system changes
- Credential supplier
- The physical product against a confirmed environment
- Property
- Populations, environment, quantities, artwork and the decision
The questions to ask in writing
Which credential type this installation is configured to accept — not what the system supports in general. Whether new credentials must join an existing numbering range. Who performs encoding and where. And whether introducing a new credential batch requires any action on the system side.
In writing, because these answers get quoted months later and because a verbal answer from a technician on site is not something anybody can act on with confidence.
Ask the integrator, in writing, which credential type the installation is configured to accept. It is the dependency everything else waits on, and it is usually a two-line reply.
Where integrators are cautious, and why
An integrator carries responsibility for a working access system, so introducing credentials they did not supply is a risk to them. Caution is reasonable rather than obstructive, and it is best met with specifics: the exact credential type, a sample for them to test, and a willingness to prove it at the doors before a run.
A supplier who bypasses the integrator to close a sale is creating a problem the property will own later.
Testing together
The most productive step in most credential projects is a sample presented at the property’s own readers with the integrator present. It settles compatibility, read behaviour and encoding in an afternoon, and it converts a three-way correspondence into a shared observation.
Record the result per reader type, so what was proven is documented rather than remembered.
When the integrator is also the credential supplier
Frequently they are, and that is a legitimate arrangement. What a property should still ask for is the same evidence it would ask of anyone: what the credential is, what documentation accompanies the run, whether goods arrive counted and range-labelled, and what is held so a reorder matches.
Convenience is a reason to buy; it is not a reason to skip the questions.
Compatibility is confirmed against the property’s lock system, credential technology and encoding requirements before production. We do not claim universal compatibility.
Questions this raises
01What should we ask the integrator first?+
Which credential type this installation is configured to accept — in writing, and not what the system supports in general. It is the dependency everything downstream waits on and it is usually a short reply.
02Our integrator is reluctant about third-party credentials. Is that unreasonable?+
No. They carry responsibility for a working access system, so caution is rational. Meet it with specifics: the exact credential type, a sample for them to test, and testing at the actual doors before any run.
03Should we just buy credentials from the integrator?+
Often a sensible arrangement — but ask the same questions you would ask anyone: what the credential is, what documentation accompanies the run, whether goods arrive counted and range-labelled, and what is held so a reorder matches.