Plan a Kisi office rollout around the employee arrival

Quick answer: Plan a Kisi office rollout by tracing the complete employee arrival, from the building entrance to the rooms that need controlled access. Confirm the deployment method and credential behavior at each boundary, then pilot those journeys with the people who will actually use them. A successful suite-door demonstration does not settle access through a landlord-controlled lobby.

An office access project can look small on a floor plan and still involve several owners. The property manager may control the street entrance, the tenant may control the suite, and another department may administer a shared equipment room. Employees experience one journey through those doors, even when the systems behind them have separate administrators.

The useful starting document is therefore an arrival map. It should describe normal working hours, early arrivals, visitors, cleaners, and people who need an alternative to a phone credential. This article turns that map into a rollout plan for a business considering Kisi, including a leased office where existing building equipment is part of the discussion.

Follow the journey from the street to the desk

Walk the building as someone starting their first day. Include the parking entrance if it affects arrival, the lobby, any elevator restriction, the suite entrance, and interior doors. Record which barriers are access controlled and which are simply part of the route. A route that works through reception at noon may fail when the reception desk is unattended at seven in the morning.

For each controlled boundary, identify the owner of the equipment, the person who approves changes, the administrator who grants access, and the team that responds when it fails. These may be four different parties. Do not place the building entrance under the tenant's change plan merely because employees use it every day.

Create a few named journeys, such as employee opening shift, visiting colleague, cleaning crew, and courier stopping at reception. Write the desired destination and time window for each. This provides a concrete basis for conversations with the property manager and keeps the project from becoming a general request to make every door behave identically.

Match the deployment to the access experience

Kisi's migration documentation states that deployment options support different access methods and credential types. Treat the chosen deployment as a design decision that affects the employee experience, not merely a way to reduce the equipment order.

Ask the proposed installer to describe the experience at each door using ordinary language. Does the person present a physical credential, use an action in an app, or use another supported method? What must already be provisioned? Which reader and controller are involved? The answer should reference the actual hardware and configuration rather than a general feature shown elsewhere in the product family.

A useful comparison has three columns: the experience employees need, the experience the proposed design supports, and the difference that requires a decision. A business may accept a different method at the shared lobby if staff understand it. It should not discover that difference during the first busy morning after the office moves.

Resolve landlord coordination before promising one credential

Kisi documents a landlord arrangement that preserves an existing system while adding selected Kisi access methods. That particular arrangement has limitations: reader-dependent mobile tap, MotionSense, and Bluetooth unlocks are not available without Kisi readers. It is an example of why a product demonstration must match the proposed building configuration.

Get the property manager's approval for the scope, access to equipment, planned interruption, and ongoing support responsibilities. Ask who will authorize employee changes when someone leaves the tenant company but still has a credential in the building's system. A tenant's internal offboarding task should include every applicable access owner, not just the software their office administrator uses.

Document what happens if the tenant changes suites or leaves the property. Decide which equipment stays, which records the business needs, and who removes access that was established for the project. Those questions may influence the preferred deployment more than a small difference in the initial device count.

Write an employee enrollment plan people can follow

Choose a small group that represents the real workforce: an everyday office user, an early starter, a part-time visitor, a manager who approves access, and someone using the approved alternative to a phone. The pilot should reveal unclear instructions and support responsibilities before the entire office receives enrollment messages.

The enrollment instructions should tell people what to expect, who the message comes from, which doors their role includes, and where to get help. Have someone outside the project team read the instructions without a live explanation. If that person cannot tell whether they have completed enrollment, the communication needs another pass.

Set boundaries for the help desk. Staff should know how to confirm a user's identity through the business's approved process and when to escalate an access request. Do not encourage employees to send screenshots containing credentials, personal information, or sensitive administrator screens into an informal group chat simply because it feels convenient during launch week.

Turn the pilot into an acceptance exercise

A pilot is useful when it produces recorded outcomes. Have a facilities representative and the intended administrator observe the same scenarios, then agree which results are acceptable. Test with real walking routes and normal business timing, while keeping safety-sensitive activities under the appropriate qualified team's control.

• Verify the employee journey at the start and end of the approved schedule, including the shared building entrance.
• Confirm a visitor reaches the intended destination through the approved reception process and receives no unnecessary room access.
• Check the selected alternative credential with the same doors and schedule as the employee role it supports.
• Remove a test user's permission, confirm the result through the agreed procedure, and document any remaining access in another system.
• Record the support path for a failed credential, unavailable phone, or door that will not latch properly.

Do not declare the pilot successful from a screenshot showing a user in an access group. Record what happened at the physical door and the corresponding administrator record. Keep failed scenarios on the issue list with an owner and a retest date. A pilot that identifies an unresolved dependency has done useful work, even if it delays the wider enrollment.

Separate launch support from routine administration

Launch week usually needs more attention than a normal week. Assign a named coordinator for employee questions and a separate person who can approve permission changes. Combining those responsibilities informally can lead a helpful responder to grant access that the relevant manager never approved.

Use a short issue log with the door, time, intended action, observed result, and resolution owner. Avoid collecting more personal information than the support task needs. Patterns in the log are valuable: repeated confusion at one lobby entrance may indicate a communication problem, while problems on one physical door may require a hardware or alignment review.

Before closing the project, move routine tasks into the business's normal workflow. Onboarding, departures, temporary access, schedule changes, and administrator reviews should not depend on finding an old installation email. The mobile credentials and key cards guide can help the business make the longer-term credential choice explicit.

Package the handover for the next office manager

The handover should describe the system the business received, including any mixed deployment. Record the door names, equipment inventory, selected access methods, relevant ownership boundaries, support contacts, and open exceptions. Keep sensitive configuration and account recovery material in the business's approved secure location rather than a public project folder.

Include a short operational exercise in the handover meeting. Ask the incoming administrator to process a hypothetical new employee, change a role, and remove a test credential using the agreed approval process. This tests whether the written instructions support the actual job. A training attendance list alone cannot show that the person knows which building administrator to contact.

For nationwide offices, reuse the structure of the handover while preserving each building's differences. A shared lobby in one city and a tenant-controlled entrance in another should not receive identical assumptions. Consistent records make those differences visible and let the business expand the program without rediscovering the same unanswered ownership questions at every location.

The takeaway

A Kisi office rollout works best when it starts with complete arrival journeys and named owners. Establish which deployment is proposed, what employees will do at each door, and how landlord-controlled access joins the tenant's internal process. Those decisions should be visible before the full workforce begins enrollment.

Use the pilot to test actual journeys and the handover to prove that someone can operate the finished system. Clear enrollment instructions, a realistic support path, and coordinated offboarding are part of the installation outcome. They help the business turn functioning hardware into access that people can use and administrators can manage.

Plan your office access project

BlueHouse Telecom works with businesses nationwide. Use the door access control planning guide to organize the building boundaries, employee journeys, and questions for a site-specific proposal.

FAQ

Can an office use Kisi while a landlord keeps another access system? There are documented deployment approaches for that situation, but the exact building equipment, permissions, and desired access methods need review. Ask for a description of the proposed arrangement and test the full journey through both owners' doors.

Should every employee use a phone credential? Make that a business decision based on the supported deployment and workforce needs. Plan an approved alternative for people who cannot or should not use a personal phone, then test its permission and support process alongside the primary method.

How many employees should join the pilot? Select enough people to represent the important roles and arrival patterns. A small group that includes early arrivals, visitors, administrators, and alternative credentials can expose more useful issues than a larger group with identical workdays.

What should the office receive at handover? Request a door and equipment inventory, approved access methods, ownership contacts, operating instructions, recorded pilot outcomes, and any unresolved exceptions. The business should also know who approves access and who handles a physical door problem after launch.