Employee presence and availability for SaaS support 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 is an operational promise. It should account for coverage hours, the employee’s current conversation, escalation rules, language or product expertise, and whether the chosen channel is staffed.

For example, a support specialist can have the presence state “active” while availability is “not accepting new visitors” because they are investigating an incident. A customer success 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. None of these cases means the presence signal is inaccurate; it means the signals have different audiences and purposes.

Kiguri’s public product materials describe member presence/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 SaaS support

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 support:** 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,” “triage,” 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 answers none of these 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 SaaS reception, visitor copy can be simple:

> Our support reception is open. Share your product area and a short description, and an available support employee will join when ready.

When no live employee is available:

> The support team is not taking live conversations right now. Leave the context of your request and we will follow up through the stated support 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. See the [Kiguri customer reception](/) and Kiguri guides for related visitor and handoff patterns.

The product 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 support 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 support specialist may accept product 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 product 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.

Common mistakes to avoid

• **Treating presence as a promise:** “Online” should not mean “a customer can interrupt me.” • **Using one status for every channel:** Chat, browser phone, video, and scheduled consultations may have different staffing. • **Leaving the offline state vague:** Tell visitors whether they can leave context, use an existing support channel, or return during coverage. • **Exposing private rooms:** A public reception should lead to approved destinations, not reveal the whole employee workspace.

A lightweight operating checklist

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 support 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

• Kiguri. (2026). *Kiguri — A virtual reception for customer inquiries*. https://kiguri.com/ • Kiguri. (2026). *Kiguri privacy policy*. https://kiguri.com/privacy • Kiguri. (2026). *Kiguri security*. https://kiguri.com/security • Kiguri. (2026). *Kiguri data processing addendum*. https://kiguri.com/dpa

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

Sources and further reading

• [Kiguri home page](/) • Kiguri workflow • Kiguri pricing • Kiguri guides

Sources and further reading

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