Key fob & key card systems · Toronto & GTA
Key cards and phone keys. No fobs to chase.
Offer supported NFC cards and Wallet keys while keeping permission changes in an agreed administration process. When somebody leaves or loses a credential, the responsible person needs to review and apply the access change; recovering the physical object is a separate task.
Make the key list easier to maintain
Who approves, issues and withdraws each permission?
Tell us how many doors and people you have. The door check comes first; cost follows, before any work.
Identify cards in circulation
Bring the reader and credential details you know.
Check what can remain
Assess existing equipment before promising compatibility.
Plan issue and withdrawal
Agree product-card quantities, administrators and ongoing charges.
In short
How is this different from a key fob system?
For buildings, gyms and offices running on fobs today
SmartphoneKey documents its own NFC cards and Wallet credentials at the reader, with portal tools for managing permissions. Existing fobs may use another technology. The property must agree issuing, loss reporting, withdrawal and any reuse process. Recorded credential activity does not independently identify a borrower or show everyone who physically entered.
Example, not a completed project
A missing card turns up after a replacement has been arranged.
Imagine a user finding an old card after reporting it missing and receiving an approved replacement. The property needs to review the intended status of the earlier permission rather than assume finding the object restores or changes it. Ask the administrator to explain the proposed process. This is an illustrative credential-lifecycle question, not a customer incident, an automatic loss-detection service or a promise about every reader configuration.
A credential-lifecycle comparison
Look beyond the first tap and the physical object.
A manageable key arrangement needs a clear issuing decision and a reliable route for later changes. Compare the proposed credential choices with that continuing job.
Make issue and ownership clear
- Identify the actual proposed credential technology and reader configuration. A product-specific card option does not establish support for an old token from another system. Keep an essential reuse requirement open until that relationship has been assessed instead of assuming similarity means compatibility.
- Associate each continuing permission with an approved purpose and the doors needed for it. A formerly shared staff or department key may have had broader access than a new individual holder requires. Review the entitlement rather than copy it automatically because it existed before.
- Include users who prefer a supported physical card and explain its issuing process. Establish who authorizes the credential and whom the holder contacts for help. A preference about a personal phone should not lead by default to borrowing another person's unrestricted key.
Make later changes repeatable
- Give holders a clear way to report loss and identify the person reviewing the affected permission. Agree replacement authorization and the handling of the earlier credential. Supplying another object or pass does not, on its own, demonstrate that the old entitlement was withdrawn.
- Explain what happens when a person leaves, a key returns or an old credential is found. Those events need to reach the access administrator through the agreed process. Do not present portal revocation capability as proof that an occupancy or staffing decision has already been received and applied.
- Keep the issuing instructions, approved door groups, help contacts and continuing charges with the handover. Explain the meaning and limits of activity records. A logged credential interaction can support the operating review without independently naming a borrower or proving somebody's full attendance.
A different credential, the same accountability
Follow a card from issue to withdrawal.
The important comparison with a fob system is how a person receives and loses permission. The object’s shape alone does not establish compatibility or control.
Issue a credential for an authorized user
SmartphoneKey describes its own NFC cards alongside Wallet keys. Assign the appropriate doors and explain the reader interaction. Do not assume a token issued by another system can be enrolled simply because both products use contactless entry.
Keep loss reporting straightforward
Tell users whom to contact if the card or phone disappears. The portal supports removal of access, but someone must receive the report and act. A replacement object does not itself establish that the old permission has been withdrawn.
Avoid an unexplained shared key
A department card or borrowed staff credential can obscure who is supposed to hold it. Consider a limited guest permission for a particular visit instead. An activity log describes the credential interaction and cannot independently identify the holder of a borrowed card.
Review credentials when circumstances change
A departing staff member, ended tenancy or changed room assignment needs a permission review. Include any old guest credentials and physical cards in that process. A different billing, HR or booking system does not automatically update access unless that exact connection is verified.
The published guides document SmartphoneKey NFC cards, Wallet credentials and administration. These management examples do not offer cloning, identify an unknown borrower or establish compatibility with every existing token system.
Where it fits
Property guides.
Review the reader and the issuing routine
Know which equipment and permissions are being compared.
Bring the existing reader or system details where known, the current door arrangement and the people responsible for access. Discuss supported phone and card choices, how a loss is reported and who applies a withdrawal. Similar-looking fobs do not establish interchangeable technology. The assessment should identify retained equipment and the proposed credential process before reuse or enrollment is treated as confirmed.
Is it the right fit?
Can the property keep each permission tied to an approved purpose?
Useful when issuing and withdrawal have responsible owners
- Fobs get lost, shared or never returned.
- People join and leave every week or month.
- You want recorded credential interactions and an accountable issuing process.
Confirm existing-token and software requirements
- You must keep every existing fob working with no change. That is decided on site.
- You need access created automatically from another system. That isn’t confirmed.
After the first credential has been handed out
Keep its purpose and its owner understandable.
A physical key and its authorization are related but different parts of the process. Review what the property does when a credential is lost, returned or assigned to somebody else.
Can a phone key and a card serve different users?
The documentation describes both credential options on the SmartphoneKey reader. Confirm the proposed package and issuing process. A person preferring a physical credential should receive an authorized option rather than use another individual’s key.
Does every existing fob technology transfer to the new reader?
That is not established. Assess the actual old equipment and tokens. A proposal should explain whether the old arrangement is retained, replaced or connected through a specifically confirmed configuration.
How do we deal with a card that was never returned?
Use the access-management process rather than rely only on recovering the object. The responsible administrator should know which permission to withdraw and how that change is confirmed. Physical possession and active permission are different things.
Can the access log prove who borrowed a card?
It does not independently establish the identity of a person holding a shared credential. Keep an issuing process suitable for the property instead of relying on an activity event as a complete identity check.
Is a spare card a complete backup for a phone?
It can provide another credential if planned and available. It does not restore a failed equipment supply or prove all outage cases are covered. Discuss the actual alternative entry and exit arrangements during assessment.
What should a manager explain about entry records?
Clarify who has administrative access and how the information will be used. The product documents activity and admin audit records, but they are not a substitute for an agreed privacy and credential-handling process at the property.
What should happen if a reported-lost card is found later?
Ask the administrator to review the intended permission in the proposed setup before the object is used again. Finding it does not establish that access has been restored or that a replacement changed its status automatically. Agree this case in the operating handover rather than leave the holder to infer the result from physical possession.
Can a returned card be handed straight to a different person?
Agree the supported issuing and reassignment process with the administrator. Review the new person's approved doors and the earlier authorization instead of assuming the object should carry every old permission. This preview performs no card change and does not establish a universal reuse procedure for another manufacturer's token.
Next step
Retire the fob drawer.
Tell us how many doors and people you have. The door check comes first; cost follows, before any work.
Request a door checkCompare the credential choice with its ongoing management
Name the assessed reader and release, supported credential options and any conversion work. Include issuing, loss response, withdrawal instruction and continuing charges. Keep unconfirmed old-token reuse separate from the documented product-specific card method and retain the person responsible for later changes.
For the Toronto/GTA review, arrange a contact familiar with today's issuing routine and the authorized equipment access. Bring model details where available without private card records. This example books no enrollment, copies no token and changes no existing permission.