Inquiry intake forms for software vendors

Why software intake needs more than a blank field

An internal team may think in product, sales, support, security, and partnerships. Visitors think in goals: evaluate a product, get help with an account, discuss implementation, or reach a partner contact. Asking them to choose an internal department can misroute the inquiry or cause unnecessary back-and-forth.

A good intake form asks only what changes routing. Name, company, relationship, and purpose may be enough to begin. A short free-text explanation lets a prospect describe the problem in their own words. An existing customer can identify a workspace or organization without submitting a password or secret key.

The intake is not a substitute for a security review, technical discovery, procurement questionnaire, or support case. It is a first context layer before a human chooses the next channel.

Start with the [Kiguri customer reception](/) and review the Kiguri guides for visitor-facing context.

A Kiguri intake sequence

Plan five steps:

1. **Welcome:** explain what the software vendor's reception handles. 2. **Identity:** ask how the visitor should be addressed. 3. **Organization:** collect company, workspace, or partner context when relevant. 4. **Relationship and purpose:** offer visitor-friendly choices and a short explanation field. 5. **Next step:** tell the visitor whether an employee is available or the inquiry has entered a queue.

The AI receptionist can guide approved questions and stop when routing context is sufficient. Preserve the visitor's own words when an employee accepts the handoff so the next person does not ask for an unnecessary restart.

Write choices that match software visitors

Useful relationship choices may include prospective customer, existing customer, implementation partner, technology partner, vendor, analyst, or other. Use only categories that the vendor can route responsibly.

Purpose choices could include evaluate the product, get help with an existing account, discuss implementation, ask about a partner relationship, or contact operations. Avoid promising a technical answer merely because a visitor selected “product question.” An available employee still needs to review the request.

Explain why a field helps. Ask for a workspace or organization name only when it lets the team locate the relationship. Never request passwords, API keys, access tokens, payment details, or confidential customer data in a public intake. The vendor should define its own secure verification and data-sharing process.

The AI may answer approved general questions about the product and reception. It should not invent integration support, uptime, security certifications, roadmap commitments, pricing exceptions, or performance claims. When the question needs a subject-matter expert, offer a human handoff.

Connect forms to roles and the queue

Assign an owner and backup for each purpose. A prospect may route to sales or a solutions host. An existing customer may route to support or customer success. An implementation inquiry may need a delivery specialist. A partner may need alliances. General questions can use a shared queue.

Kiguri includes employee roles, member presence or status, and a shared response queue. Use them to decide whether a live handoff is possible. A person marked available may still be in a customer call or lack the role needed for a technical question.

When nobody is available, confirm that the inquiry has been received and explain the follow-up. Preserve the visitor's context. If a specialist joins, explain the transition and pass the summary before adding them to a new channel.

Use queue states that match real software operations, such as new, claimed, waiting for visitor, waiting for specialist, and complete. A claimed request should have an owner and next action; it should not imply that an incident is accepted, a product commitment has been made, or a security review is complete. Write an after-hours message before launch and update it when support hours or staffing change.

Keep the form separate from a formal support case or security disclosure. If a visitor reports an urgent account issue, an incident, or a vulnerability, direct them to the vendor's approved channel rather than asking for secrets in the reception. This protects the clarity of the public intake while allowing the responsible team to use its own process.

Review and improve the form

Test a prospect, existing customer, implementation partner, analyst, and after-hours visitor. Check whether the questions are understandable, whether the queue has an owner, and whether visitors know what happens after submission.

Read a sample of inquiry threads. If prospects ask for a field that is missing, add one non-sensitive prompt. If a field is never used, remove it. If many people choose “other,” simplify the purpose choices. Do not claim higher conversion, faster support, stronger security, better performance, or compliance from the form without evidence and appropriate review.

Close each inquiry with an explicit owner and next action. The host can explain whether sales, support, implementation, or partnerships will follow up, whether another approved channel is needed, or whether the inquiry remains queued. Review the boundary with every queue owner so visitors receive consistent guidance across locations and time zones.

Confirm current Kiguri pricing, visitor rules, and workspace limits before publishing a field requirement or feature promise.

Assign one person to maintain approved answers and intake wording as the product and support process evolve. Review that owner monthly with sales and support.

This keeps the intake aligned with actual product and support ownership daily, too, now, here.

FAQ

How many fields should a software intake form have?

Start with the minimum context that changes routing: identity, company or workspace when relevant, relationship, and purpose. Add a field only when an employee can explain how it will be used.

Should the form ask for an API key or password?

No. Keep secrets out of a public reception. Use the vendor's approved secure process after a human handoff.

Can prospects and customers use one form?

Yes. Relationship and purpose choices can route each inquiry while preserving one recognizable arrival.

What if a technical specialist is unavailable?

Place the inquiry in a response queue with an honest follow-up message. Do not promise an immediate technical answer.

Make every submitted detail useful

A software-vendor inquiry form should be short, understandable, and connected to a real owner. Kiguri combines branded arrival, AI-assisted intake, roles, presence, a response queue, and controlled follow-up while people remain responsible for product and customer decisions.

[Explore Kiguri](/) and design intake around the visitor conversations your software team can genuinely support.

Sources and further reading

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

Sources and further reading

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