Reception map design for IT service desks

Begin with a visitor-first map brief

Write a one-page brief before adding rooms. State who visits the desk, which choices visitors need, which role owns each choice, and what happens when no person is available. Include employees, customers, implementation partners, vendors, and after-hours visitors. If a destination cannot be explained to one of those audiences, it may belong in internal documentation rather than the public map.

A practical map brief might define:

1. **Reception:** general orientation and bounded AI intake. 2. **Employee workspace help:** internal workspace or onboarding questions. 3. **Customer support:** account or product context for a human conversation. 4. **Implementation and partners:** rollout or project coordination. 5. **Other question:** a safe path for requests that do not fit a label.

For each destination, name the host role, approved orientation text, expected context, and fallback queue. Use roles instead of individual names where possible so the design survives staff changes. Review current Kiguri plan details before publishing membership or guest-day statements.

Use hierarchy instead of a crowded floor plan

Visitors should see one main reception and a small number of meaningful destinations. Place general orientation first. Group related conversations under a broad area, such as Support, Customer success, or Partnerships, and let intake details determine the human role. Avoid a map with dozens of nearly identical rooms; it asks visitors to become experts in your org chart.

Use short labels and a sentence of context. “Customer support” is clearer than “Tier 1 / Tier 2 / escalation pod.” “Implementation conversation” is easier for a partner than “Professional services intake.” If internal terminology is essential, provide it after the visitor has chosen a purpose rather than making it the first visual decision.

The Kiguri map preview can help your team discuss the relationship between reception, destinations, and routes. Keep the map as an aid to conversation, not as a claim that every room is available, private, or staffed at all times.

Pair visual destinations with intake questions

A map alone cannot understand why someone is visiting. Combine it with a branded reception and an AI receptionist that asks approved questions: name, organization or workspace, broad purpose, and a concise description. The visitor can choose a destination after that context is collected, and the host can receive the summary without restarting the exchange.

Keep the questions safe for a public entry point. Do not request passwords, API keys, access tokens, private encryption details, or full incident logs. For an account compromise, urgent recovery request, or potential security incident, orient the visitor to the approved secure or emergency channel. The map should never imply that selecting a room opens an incident ticket or starts recovery.

Use an “Other question” path intentionally. It can route to a general service-desk role or response queue while a human reviews the context. An inclusive fallback is better than forcing a visitor into an inaccurate room and making staff correct the route later.

Make availability visible but limited

Presence can show whether a role is available for a conversation, in a conversation, or away. Use descriptions that reflect the scope of availability. A host may be open for a customer question while another role handles incidents. A visible status should help a visitor choose a destination, not create an expectation of immediate technical action.

Set a fallback for every room. If no host is present, keep the inquiry in the response queue and provide an honest message about the next human step. Document who reviews the queue during support hours, holidays, and rotations. Do not call this an SLA unless your organization has separately defined and verified one. The map does not guarantee response time, uptime, recovery, security, or resolution.

When a visitor reaches a host, the host can choose chat, browser phone, video, screen sharing, or a private room. Use the channel that fits the conversation and your policies. A private destination is not proof of confidentiality, compliance, or secure handling; the service desk decides what information may be shared.

Protect the boundary between public and internal maps

Do not place incident bridges, on-call rotations, personal schedules, customer-specific rooms, or sensitive project names on a public reception map. Broad labels offer orientation without publishing details that should remain inside approved systems. If employees need an internal-only area, present it after the visitor has identified the relevant organization or workspace and apply your own access requirements.

Keep map content separate from technical status. If a system is unavailable, update the service desk's approved status process rather than adding a warning to a decorative room. A map can tell visitors where to ask; it should not claim that a room is monitoring a system or coordinating recovery.

Test the design with realistic arrivals

Run a short usability review with people who represent each audience. Ask an employee to find workspace help, a customer to find product support, a partner to find implementation, and a vendor to find a delivery contact. Ask each person what they expect to happen after selecting the room. If someone expects a diagnosis or guaranteed response, revise the wording.

Review handoff context with service-desk staff. Did the host receive the visitor's purpose and organization? Was the route clear? Did the map expose a private label? Check after-hours behavior, queue ownership, and any AI answer that could be outdated. Retire rooms without owners and simplify destinations that visitors repeatedly misunderstand.

Keep a map register with labels, owner roles, approved descriptions, public placements, and review dates. When a reorganization occurs, update the register and reception wording together. Measure internal routing quality if useful, but do not market unverified performance, security, recovery, compliance, or SLA outcomes.

FAQ

Is reception map design the same as designing an IT service catalog?

No. A map is a visitor-facing orientation layer. It can point to broad roles and purposes while your service catalog and technical systems retain detailed services, ownership, and records.

How many destinations should a public map show?

Show the smallest set that helps your audiences choose a next step. Broad destinations with current owners are usually easier to understand and maintain than a room for every internal team.

Can an AI receptionist send someone to a room automatically?

It can use approved context to guide a visitor toward a role or destination. Human staff remain responsible for technical decisions, sensitive information, and incident procedures.

Should a security incident have its own map room?

Keep sensitive incident destinations out of a general public map. Orient visitors to the approved channel and let authorized human staff handle the incident process.

Does a private room guarantee secure or compliant support?

No. A private room is a conversation destination. Follow your own policies for access, retention, confidentiality, and regulated work.

Sources and further reading

• Kiguri map preview • [Kiguri customer reception](/) • Kiguri pricing and plan overview • Kiguri guides

Sources and further reading

Kiguri product overview, Kiguri pricing, security information, and Kiguri guides.