Guest-day pricing model for software vendors

What this planning model means

Treat a guest-day as a way to estimate visitor activity over a day, not as a promise that every visitor interaction has the same billing treatment. Separate:

1. **Members:** employees who need roles, presence, queue access, or private workspace access. 2. **Guests:** prospects, customers, partners, vendors, and community visitors arriving through a reception link. 3. **Occasional participants:** people joining one consultation without needing permanent internal access.

This distinction prevents a vendor from buying a permanent seat for every prospective participant while still recognizing that employees are needed for a responsible handoff.

Public Kiguri plan signals

Kiguri public materials reviewed on August 8, 2026 describe a Free plan at $0 for up to eight members, with public reception and visitor links, inquiry forms/basic handoff, member presence or status, three maps, and a stated map-tile allowance. The Business plan is listed at $12 per user per month and includes two guest-days per paid seat every day, AI reception, a response queue and employee handoff, browser phone, longer meetings, and private consultation rooms. Custom pricing is described for higher seat or verified-visitor allowances and additional review or onboarding needs.

These are planning inputs, not a permanent price promise. Terms and limits can change. Verify the live Kiguri pricing and workspace settings before using these details in a proposal.

Calculate a starting requirement

First count employees who need to own or accept visitor inquiries. Do not count every engineer or specialist if only sales, support, success, or implementation roles need queue access. Then estimate a typical day and a busy day: new visitors, concurrent conversations, and roles needed for live handoff.

If the Business allowance is still two guest-days per paid seat each day, a vendor can compare the seats it genuinely needs with the visitor pattern it expects. A team with four customer-facing seats would plan around the allowance associated with those seats, then confirm how Kiguri defines a guest-day and whether it covers actual use. This is a prompt for verification, not a capacity guarantee.

Write assumptions plainly: “Three customer-facing members need queue access; most visitors are prospects or existing customers; a product event may create a temporary spike.” This is more useful than choosing a plan from a single website traffic number.

Use a visitor worksheet

Create four columns: visitor purpose, expected busy-day visitors, employee owner, and next destination. A product prospect may need sales or solutions and a product room. An existing customer may need support and a private conversation. An implementation partner may need delivery and browser video. A general question may stay in chat or a queue.

Review the worksheet with queue owners. If a role cannot accept visitors during a release or incident, record the backup. If a visitor purpose rarely needs a live conversation, do not buy capacity based on an imagined meeting. Update the worksheet when a campaign, product launch, or support-hours change alters demand.

Match the plan to the workflow

Free can be useful for testing a branded reception, visitor links, inquiry forms/basic handoff, presence, and a small map when published limits fit. Use that test to learn which intents arrive and whether the team can own the queue.

Business becomes relevant when the vendor needs AI reception, a response queue and employee handoff, browser phone, longer meetings, or private consultation rooms as a repeatable operation. Buy seats for employees who need those responsibilities, not every future participant.

Custom may be worth discussing when visitor volume, verified visitors, seats, phone needs, retention or DPA review, guided onboarding, or priority support fall outside the standard description. Describe the desired workflow and access boundary, then ask Kiguri to confirm current options.

Plan for peaks and after-hours

Demand may spike around launches, events, partner programs, or onboarding windows. Separate normal days from known peaks. Decide who reviews the queue when support and engineering teams are focused elsewhere. Write an after-hours message that accurately states whether visitors can leave an inquiry and when it will be reviewed.

Presence and roles can make live language truthful. A person may be online but unavailable for an unplanned technical call. A queued response is better than a transfer nobody owns. Review retention and access as visitor volume grows because more inquiries mean more context in the queue.

Do not claim that a pricing model improves conversion, support time, utilization, security, product performance, or compliance without measuring your own operation. Confirm visitor rules and workspace configuration before a public commitment.

Record the date of every pricing review because terms can change. Assign one owner for the worksheet and document assumptions whenever seats, campaigns, or visitor purposes change.

Review the worksheet after every major product launch or support-hours change. Ask whether the visitor purpose still maps to the same role and destination. If not, update the queue owner before buying more capacity. The model is most useful when it describes the operation the team can actually support.

Keep one pricing owner and record the date and source for every assumption. Review it with finance and customer operations before each new campaign.

This keeps pricing assumptions visible to the whole vendor team every day, too, now, here, daily.

FAQ

Is a guest-day a Kiguri billing definition?

This article uses guest-day as a planning model. Exact billing terms and allowances come from the current Kiguri pricing page and workspace agreement.

How many seats should a software vendor plan for?

Start with employees who need queue ownership, presence, routing, or private follow-up. Add seats when a real role requires them.

Is the Free plan enough for a small vendor?

It may be a useful starting point when published member, visitor, map, and handoff limits fit. Verify current details before relying on a feature.

When should we discuss Custom?

Ask when visitor volume, seats, verified visitors, phone needs, retention review, onboarding, or support expectations do not fit the standard description.

Plan for responsibility as well as visitors

A guest-day planning model helps a software vendor separate who works in the virtual office from who visits it. The practical decision combines member ownership, visitor patterns, live handoff needs, private destinations, and honest after-hours operations. The live pricing page remains the authority for current numbers and limits.

Review Kiguri pricing and then [explore the customer reception](/) with your actual visitor intents and accountable hosts.

Sources and further reading

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

Sources and further reading

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