Reception map design for SaaS support teams

Start with the visitor journey, not the floor plan

Before placing a room, write the shortest useful visitor journey:

1. The visitor opens a branded reception link. 2. The visitor explains who they are and why they are visiting. 3. The AI receptionist answers approved questions or collects missing context. 4. The inquiry reaches an available employee when human help is needed. 5. The conversation continues in the least complicated channel that fits the request.

The map should make this sequence visible. It should not require a customer to understand whether “Customer Operations,” “Technical Enablement,” or “Tier Two” owns a problem. Those are internal decisions. The visitor needs a clear welcome point and a destination that reflects their goal.

Five design decisions for a useful reception map

1. Make reception the visual anchor

Place the public welcome point where a first-time visitor will find it immediately. Use a label such as “Customer reception” or “Support reception,” and include a short explanation of what visitors can ask. Do not hide the entry behind decorative rooms or a long path.

The reception link and the map should reinforce each other. A support button, onboarding message, and customer success invitation can all point to the same branded arrival. Consistency teaches customers where to begin.

2. Show only destinations that change the next step

Every visible room adds a decision. Keep the public map small enough that a visitor can scan it quickly. A support area, customer success area, meeting room, and private consultation destination may be enough for a first version.

Do not expose every employee desk merely because the map can contain them. Visitors should not need to browse internal workspaces to find a person. Kiguri's reception and response workflow can collect context and route the inquiry to an available employee without turning the map into an unrestricted directory.

3. Use customer language

Labels should describe the outcome a visitor wants. “Product help,” “Onboarding,” and “Talk to an employee” are generally easier to interpret than abbreviations or internal project names. If the team uses a specialist term in the employee workflow, translate it into visitor-facing language at reception.

Write one sentence for each destination: what happens there and when should a visitor choose it? If the answer is not clear, the destination may not belong on the public layer.

4. Separate public, shared, and private spaces

Reception is public. A meeting room may be shared with invited visitors. A private consultation room is intended for a controlled conversation after an employee has joined. Design these as different access states even if they sit near each other on the visual map.

Kiguri supports private rooms and controlled visitor destinations in its customer-facing workflow. Confirm the current visibility and access behavior in your workspace before publishing. A persuasive map is not worth exposing an unintended room.

5. Give each destination an owner

The map cannot make an employee available. Before launch, decide who responds when a visitor chooses a path or submits an inquiry. Presence and status can help the team communicate availability, while the response queue gives the inquiry an operational place. If no one is available, the reception should set a realistic expectation for what happens next.

Map layouts for common SaaS support needs

The simple support lobby

Use one reception, one support destination, and one private consultation room. This is a strong first map for a small team. It minimizes choices and lets the AI receptionist gather the details that determine ownership.

The support and onboarding split

Place “Product support” and “Onboarding and success” near the reception. The labels distinguish common visitor goals without requiring a complex department tree. An employee can still reroute the inquiry when the initial purpose changes.

The customer and partner lobby

A team that receives both customers and partners can use two visitor-facing destinations, provided the distinction changes the next conversation. Keep private employee rooms behind the controlled handoff rather than placing them on the public route.

Write the map copy before decorating it

For each public destination, prepare three short pieces of copy:

• a label that fits on the map; • a one-sentence description of the help available; • a next-step instruction after the visitor arrives.

For example, “Product support” can explain that a visitor will share a short description and may be connected to an available employee. “Customer success” can explain that the destination is for onboarding or a planned account conversation. Avoid promising instant live help unless the team can provide it consistently.

Test the reception as an outsider

Map owners know what each label means, so internal review alone is not enough. Test with a colleague who did not design the map. Ask them to find the correct starting point, explain what they think will happen, and identify which destination they would choose for a product question.

Then test the operational transitions. Submit a routine question, a request that needs screen sharing, and a message arriving when no employee is available. Check that the inquiry carries identity, company, and purpose context into the response workflow. Confirm that a private consultation destination is offered only when appropriate.

Keep the design current

Reception maps age when teams change. Review public labels after a reorganization, a support-hours change, or a new customer journey. Remove a destination that no longer has an owner. Update the welcome copy when the available channels change.

If the workspace uses map limits or plan-specific features, verify the current Kiguri plan before describing a number in public copy. Product plans and availability can change; the map should never promise a capability the workspace has not enabled.

Frequently asked questions

How many rooms should a first reception map have?

Use the fewest rooms that make a real visitor decision clearer. A reception, one or two customer-facing destinations, and a private consultation option are often enough to begin. Add rooms only when they have a clear owner and purpose.

Should the map show employee names?

Not necessarily. A customer usually needs the right kind of help, not an internal roster. Let reception intake and employee availability guide the handoff, and expose named destinations only when the team intentionally wants visitors to use them.

Can the same map support chat, video, and screen sharing?

The map can lead visitors into the Kiguri conversation workflow, where the employee chooses a suitable continuation such as chat, browser phone, video, screen sharing, or a private room. Confirm the current workspace and plan settings before promising a specific channel.

How can I keep private rooms off the public path?

Use reception-first entry and controlled visitor destinations. Review the map as an unauthenticated visitor and verify that private rooms require the intended employee-led transition.

What should I read next?

See the [Kiguri customer reception overview](/), review pricing and plan details, and explore the Kiguri guides for related visitor workflows.

Final design checklist

Make reception obvious, keep the public map small, label destinations in customer language, separate public and private access, assign an owner to every path, and test the complete intake-to-handoff journey. A good reception map does not try to model the whole company. It gives a visitor confidence about where to start and gives an employee enough context to help.

Kiguri's map tools provide the spatial layer; the reception and human handoff provide the conversation. Design them as one journey and the virtual office becomes a practical front door for SaaS support.

Sources and further reading

• [Kiguri customer reception](/) • Kiguri pricing and plan information • Kiguri security information • Kiguri guides

Sources and further reading

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