Guest-day pricing model for healthcare clinics: planning virtual reception capacity

What a guest-day means in a clinic workflow

Define the unit before putting a number beside it. A guest-day is a visitor session that starts at the clinic's public Kiguri link and ends when the visitor receives an administrative answer, is handed to a clinic employee, or is given the clinic's approved next step. If the same visitor returns on another day for a separate request, count another guest-day for planning. If a visitor moves from chat to browser phone during one session, keep it as one guest-day rather than counting two people.

The unit should not be used to infer a patient's medical complexity or urgency. It only describes the amount of reception activity a team expects. A clinic may create separate estimates for general scheduling information, billing or document questions, directions, and service information. These categories help operations teams plan queue coverage; they do not replace the clinic's own clinical or emergency pathways.

Write the definition into an internal planning note. Include the time zone, business hours, whether after-hours messages count, and whether a transferred conversation remains the same session. A shared definition prevents a finance spreadsheet from counting guest-days differently from a front-desk schedule.

Build a simple guest-day estimate

Start with a conservative weekly baseline. Review approved administrative inquiry records, website contact volume, event registrations, or other sources the clinic is permitted to use. Separate visitor sessions from messages: one visitor may send several messages while clarifying a single request. Then identify the busiest expected day and add a scenario for a seasonal or campaign spike.

A practical worksheet can include:

• expected guest-days on a typical weekday; • expected guest-days on the busiest weekday; • percentage needing an employee handoff; • percentage needing a second channel such as browser phone or video; • average minutes an employee spends after handoff; • coverage hours and backup coverage; • number of locations or public reception areas represented.

For example, a clinic might plan for 30 guest-days on a normal day, 50 on a busy day, and 70 during an outreach event. If 40 percent need a human response, the team can estimate handoff workload without pretending that the AI should answer every question. The result is an operational range, not a guaranteed forecast.

Connect the estimate to Kiguri's public workflow

Kiguri's visitor journey gives the estimate a concrete shape. A clinic can publish one branded reception link from its website or administrative emails. The AI receptionist can ask for a visitor's name, organization when relevant, and purpose. A summary can enter a shared response queue so the right available employee can review the context.

The guest-day model should therefore distinguish between reception activity and employee activity. A visitor who receives a short approved location answer may use little staff time. A visitor whose administrative question requires a scheduled browser call may use more. The model can assign planning bands such as light, standard, and extended handoff rather than claiming a fixed duration for every session.

Keep the boundaries explicit. The AI should not diagnose, assess symptoms, recommend treatment, decide urgency, or collect detailed clinical histories for this workflow. If a visitor raises a medical concern, the reception should point to the clinic's approved instructions and established channels. The guest-day estimate is not a substitute for those directions.

Compare plan scenarios without confusing pricing

Once the range is clear, compare three scenarios: baseline, high-volume day, and multi-location expansion. For each, list the employees who need access, the reception areas visitors can see, and the queue coverage required. Then open the current Kiguri plans and verify which plan structure fits the clinic's member count and intended use. Public prices and inclusions can change, so keep the pricing page as the source of truth.

Do not present a guest-day estimate as a Kiguri invoice, overage threshold, or promised capacity. A sentence such as “we plan for 50 visitor sessions on a busy day” is materially different from “Kiguri bills 50 guest-days.” The former helps the clinic staff; the latter would require current contractual documentation.

For a small practice, the useful comparison may be a few employees sharing a queue. For a group with several locations, the question may be whether one public map and multiple reception zones make sense. A clinic can also model a quiet period in which the queue captures messages and staff respond during published administrative hours.

Use the guest-day number to design coverage

Coverage is the operational value of the model. Assign an owner for new queue items, a backup during breaks, and a person who reviews unresolved administrative requests at the end of the day. Set a clear visitor message for times when no employee is available. The message should describe when the clinic reviews the request and where to find approved general information; it should not promise immediate contact with a clinician.

Map labels can make the estimate easier to act on. Public destinations might include Front desk, Scheduling information, Billing questions, and Visitor information. Employee-only rooms should remain outside the public visitor view. When an employee decides a conversation needs a private room, the guest-day remains one journey even though the context moves to a different space.

Review the model after launch

After publishing the reception link, review the estimate at a regular operations meeting. Compare planned guest-days with actual administrative sessions, queue wait patterns, handoff categories, and repeated questions. If most visitors ask for directions, improve the public information. If many sessions wait for the same employee, adjust coverage or clarify ownership. If the clinic adds a location, create a separate scenario instead of silently changing the baseline.

Avoid using automated response volume as evidence of clinical quality, patient safety, or compliance. Review access, retention, and data-handling decisions with the clinic's own privacy, security, and legal owners. The Kiguri security information is a starting point for product questions, not a certification for a clinic's particular workflow.

Frequently asked questions

Does Kiguri charge healthcare clinics per guest-day?

This article does not make that claim. Guest-day is an operational planning unit for estimating visitor activity. Check the current Kiguri pricing page and the clinic's agreement for actual plan and billing terms.

What should count as one guest-day?

Count one visitor's administrative journey during a defined day, even if the conversation moves between chat and an employee handoff. Document your time zone, hours, and treatment of after-hours messages so every team uses the same definition.

Can a guest-day model predict staffing perfectly?

No. It gives the team a range for planning queue coverage. Review real visitor patterns and update the baseline as services, locations, and hours change.

Can the AI use a guest-day estimate to triage medical requests?

No. The model is administrative. The AI should not diagnose, assess symptoms, recommend treatment, or decide urgency. Medical and emergency questions must follow the clinic's approved channels and instructions.

Is a guest-day model a compliance assessment?

No. It is a capacity and workflow worksheet. Clinics must evaluate their own privacy, security, records, and communications requirements with the appropriate professionals.

Sources and further reading

• [Kiguri virtual office and reception](/) • Kiguri pricing and plans • Kiguri security information • Kiguri Guides

Sources and further reading

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