Guest-day pricing model for universities

Why use a guest-day unit?

Monthly visitor totals hide the operational shape of an event. Two universities might each report 600 visitors in a month, but one may receive a steady trickle while the other receives 400 inquiries in a four-hour guest day. The peak pattern affects reception wording, queue staffing, employee availability, and the number of conversations that may need a private follow-up.

A guest-day unit keeps the estimate grounded in an actual schedule. Define the unit before calculating:

• the event date and public opening hours; • the number of visitors expected to open the reception; • the percentage likely to ask a question; • the percentage likely to request a human handoff; • the number of staff members who will be available; and • how many follow-up conversations may continue after the event.

The model is useful even when the event is small. It makes hidden assumptions visible to the offices sharing the budget.

The four numbers to estimate first

1. Reception visitors

Count people expected to open the branded guest-day link, not every person registered for an event. If a registration system sends one link to a household or a group, decide whether the unit is a browser session, a named contact, or an inquiry. Keep the definition consistent across scenarios.

2. Qualified inquiries

Estimate how many visitors will provide a purpose that an administrative team can route. A person who only reads an approved answer may not create a live queue item. A person who asks where to discuss a partnership or event may become a qualified inquiry.

3. Human handoffs

Estimate the share of qualified inquiries that need an employee. The AI receptionist may answer approved general questions, but a nuanced administrative conversation usually benefits from a human owner. Handoffs are the number most likely to drive staffing needs during the peak window.

4. Follow-up conversations

Some visitors will not need a live conversation on the guest day. Others may enter a private room, schedule a browser call, or continue in chat after the event. Record those as follow-up conversations so the event plan includes the second wave of work.

A simple guest-day formula

Use a worksheet with three scenarios: conservative, expected, and high-volume. For each scenario, calculate:

**Qualified inquiries = reception visitors × inquiry rate**

**Human handoffs = qualified inquiries × handoff rate**

**Peak concurrent conversations = human handoffs per peak hour × average conversation minutes ÷ 60**

For example, an expected scenario might assume 240 reception visitors, a 35% inquiry rate, and a 50% human-handoff rate. That produces 84 qualified inquiries and 42 anticipated handoffs. If 24 handoffs arrive during the busiest hour and the average conversation is 10 minutes, the rough concurrent conversation estimate is four. These are planning inputs, not performance promises. Replace them with the university's own event data after each guest day.

Add a 10–20% review margin when the event is new or the visitor estimate is uncertain. A margin is not a claim that the platform will scale to any volume; it is a reminder to validate limits and staffing before the event.

Separate platform cost from event cost

Budget owners often mix three different costs:

1. **Workspace or platform cost:** The current Kiguri plan, user seats, or other published usage terms. 2. **Preparation cost:** Map design, reception copy, approved answer review, testing, and staff training. 3. **Event operating cost:** Employee hours, moderator coverage, follow-up work, and any university systems connected to the guest-day workflow.

Keep these lines separate. A short event may require significant preparation even if platform usage is modest. Conversely, a university that already runs a Kiguri workspace may only need to add a temporary destination and review its visitor path.

Kiguri's public pricing page is the authoritative place to review current plan information. The public product materials have described a Free plan for up to eight members, a Business plan at $12 per user per month, and custom volume arrangements; these details can change. Confirm current limits, included features, billing terms, and whether a guest-day scenario requires additional seats or a different arrangement before approving a budget.

Estimate the people required for the map

A guest day usually needs more than one content editor. Assign an owner for each visitor destination, a person who reviews AI answers, and a coordinator who watches the response queue. If a destination belongs to a library, research, or events office, that office should approve the wording and fallback message.

Presence information can make the plan more honest. Mark which employees are available during the guest-day window and which conversations they can accept. If nobody is available for a destination, the reception should offer an accurate follow-up path instead of displaying a live handoff option that cannot be fulfilled.

Design a guest-day map without overbuilding

Create a small event map: Welcome, Research and Partnerships, Events and Community, Library and Learning, and Private Meeting Rooms. Each destination should have one sentence explaining its purpose. Avoid recreating every physical building or publishing an internal staff directory for a one-day event.

Use the Kiguri map preview to test labels and order. Ask a first-time visitor to choose a destination without coaching. If they cannot explain why they selected it, rewrite the description or merge the destinations.

Include a content and staffing checklist

Before the guest day, confirm:

• the branded reception link and event hours; • identity, organization, and purpose prompts; • approved AI answers for logistics the office can maintain; • the employee queue and presence schedule; • the human handoff message; • the private-room or browser-call options; • the fallback when no employee is available; and • the owner for post-event follow-up.

Run a short rehearsal with one person acting as a visitor and another acting as an employee. Test both a successful handoff and a no-availability path. Do not place unverified event times or promises in the AI knowledge content.

Review the model after the event

Record actual reception visitors, qualified inquiries, handoffs, peak concurrent conversations, unanswered questions, and follow-up volume. Compare the actual numbers with the conservative, expected, and high-volume scenarios. The variance helps the team improve the next guest-day budget and map rather than turning one event into a permanent assumption.

Also review visitor experience. Which destination labels caused confusion? Did people repeat their purpose after handoff? Did staff know which queue to watch? A cheaper plan is not useful if the visitor cannot find the right office, and a larger plan is not automatically better if the map and ownership are unclear.

FAQ

Is this guest-day model an official Kiguri calculator?

No. It is a university planning framework for estimating visitor activity, staffing, and questions to confirm with Kiguri. It is not a quote or a guarantee of plan capacity.

Does one guest day require a separate Kiguri plan?

Not necessarily. The answer depends on the university's existing workspace, seats, expected usage, and current Kiguri terms. Review the pricing page and confirm the scenario directly before purchase.

Can an AI receptionist handle every guest-day question?

It should answer only approved, maintainable information. Route questions that require institutional judgment or a specific office to a human employee.

Does this model cover admissions, emergency response, or campus security?

No. It is limited to administrative visitor orientation, map design, intake, and handoff planning. Use the university's designated systems for those other responsibilities.

What if the event has more visitors than expected?

Use the high-volume scenario, maintain a clear fallback message, and confirm platform limits and staffing before the event. The model is a planning aid, not a promise of unlimited capacity.

Sources and further reading

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

Turn a guest day into a repeatable plan

A guest-day model helps a university discuss the full operating picture: visitors, inquiries, handoffs, staff coverage, preparation, and follow-up. Pair those assumptions with a small, understandable Kiguri map and a carefully reviewed reception. Then confirm current plan details and run a rehearsal before the event. The result is a budget conversation grounded in the visitor journey rather than an arbitrary headline number.

Sources and further reading

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