Employee presence and availability for customer success teams

Presence and availability answer different questions

Avoid confusion by giving each state a separate question.

**Presence asks:** Where is the member, and what is their current workspace status? A member may be signed in, active in a map, in a meeting, away, or offline. Presence is useful for coworkers coordinating work and for understanding whether a person is likely to see an internal notification.

**Availability asks:** Can this team member accept a customer inquiry through the reception right now? Availability should account for coverage hours, the employee's current conversation, escalation rules, language or service experience expertise, and whether the chosen channel is staffed.

For example, a customer success specialist can have the presence state "active" while availability is "not accepting new visitors" because they are investigating an incident. A manager can be present but available only for scheduled calls. A specialist can be marked unavailable in the public reception while still working asynchronously on a queue.

Kiguri's public materials describe member presence or status as part of the workspace experience and describe an inquiry flow that can reach an available employee. Teams should preserve that separation in their own labels, policies, and visitor messages.

A practical state model for customer success teams

Most teams do not need dozens of statuses. A small set is easier to operate and explain:

• **Present (internal only):** The employee is in the workspace and can see team activity, but no live customer promise is implied. • **Available for live customer success:** The employee can accept a new reception handoff in the stated channel. • **Busy with a visitor:** The employee is already handling a customer conversation. A queue or follow-up path should be offered instead of another live handoff. • **Available for scheduled work:** The employee can join a planned consultation but is not accepting unscheduled inquiries. • **Follow-up only:** The employee can review a request later, with an honest response expectation set by the team. • **Offline:** The employee is not monitoring the reception. The visitor should be directed to the team's documented follow-up route.

The names can differ, but every customer-visible state should answer what happens next. Avoid exposing internal labels such as "deep work," "backstage," or "on-call rotation" unless the visitor understands them.

Why this distinction matters to visitors

A visitor usually wants to know three things before submitting an inquiry:

1. Is this the right place to ask? 2. Will someone respond now or later? 3. What information should I prepare?

Presence alone does not answer these questions reliably. An online map can suggest an immediate conversation even when that person is in a private meeting. Keep internal presence useful to members while publishing a separate, conservative availability message to visitors.

For a customer success reception, visitor copy can be simple:

> Our customer success reception is open. Share your service experience area and a short description, and an available customer success employee will join when ready.

When no live employee is available:

> The customer success team is not taking live conversations right now. Leave the context of your request and we will follow up through the stated customer success channel.

Do not show "available now" merely because someone has an active browser session. The public message should reflect the handoff policy, not a technical heartbeat.

How Kiguri fits into the workflow

Kiguri provides a front door for customer conversations: a visitor enters through a branded reception link, shares identity, company, and purpose, and meets an AI receptionist or inquiry intake flow. The request can move into a response queue and then to an available employee. Depending on the team's setup and current plan, the conversation may continue by chat, browser phone, video, screen sharing, or a private consultation room.

The service experience should not be described as deciding every staffing question automatically. A team still defines which employees accept live inquiries, which requests need a specialist, and what happens outside coverage hours. Kiguri is the reception and connection layer; the customer success operation owns the service policy.

Build a visitor-aware handoff policy

1. Define who may accept a live handoff

List the roles that can take a new conversation and the request types they cover. A general customer success specialist may accept service experience questions, while billing, security, or implementation requests may require a named owner. If no qualified employee is available, route the visitor to follow-up rather than offering a misleading live option.

2. Set the minimum intake context

Collect only information that changes the next action: visitor name, company or workspace, purpose, affected service experience area, and desired outcome. Do not request passwords, secret keys, or sensitive credentials through a public reception. A concise summary lets the employee begin with the issue instead of asking the visitor to repeat the opening exchange.

3. Publish coverage and channel expectations

State whether the reception is staffed for live chat, browser calls, or scheduled meetings. A team may be available for chat while declining new video calls, or it may accept a call only after an employee reviews the request. Channel-specific availability prevents a generic "someone is online" message from becoming an accidental promise.

4. Define the busy and offline paths

When a member is already with another visitor, keep the inquiry in the response queue or collect a follow-up request. State what the visitor should expect next and which team owns the response. If the team does not offer a guaranteed response time, do not invent one in the reception copy.

5. Confirm the handoff in both views

The employee should receive the visitor's purpose, context, and any approved AI response. The visitor should see that the request was received, whether a person is joining now, and which channel will be used. If a private consultation room or screen share is needed, explain the transition before opening it.

FAQ

Is member presence the same as employee availability?

No. Presence describes a member's workspace state. Availability describes whether the employee or team can accept a new customer inquiry under the published handoff policy.

Should visitors see individual employee presence?

Only when the team has a clear reason and the displayed state cannot be mistaken for a live-service promise. In many cases, a team-level reception message is safer and easier to keep accurate than a directory of individual states.

Can Kiguri automatically decide who is available?

Kiguri's public workflow describes reception, inquiry context, a response queue, and handoff to an available employee. The team remains responsible for defining coverage, roles, escalation rules, and the exact availability policy. Confirm current workspace behavior before publishing detailed automation claims.

What should happen when everyone is busy?

Keep the visitor's context in a queue or collect a follow-up request, then explain the next step honestly. Do not imply that a live employee is joining if the team is not monitoring the reception.

How should a customer success team measure this policy?

Track repeat explanations, queue age, handoffs that find the right owner, channel changes, and follow-ups that lack an owner. These operational signals help improve staffing and intake; they are not guaranteed response-time or conversion claims.

Sources and further reading

• Kiguri. (2026). *A virtual reception for customer inquiries*. https://kiguri.com/ • Kiguri. (2026). *A virtual reception for customer inquiries*. https://kiguri.com/ • Kiguri. (2026). *A virtual reception for customer inquiries*. https://kiguri.com/ • Kiguri. (2026). *A virtual reception for customer inquiries*. https://kiguri.com/

Verify live labels, plan limits, and channel availability before publication.

Sources and further reading

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