Inquiry intake forms for IT service desks

Start with the decision the form must support

Before writing a question, name the next human decision. If the host only needs to know whether a visitor is an employee, customer, partner, or vendor, ask for that audience. If ownership depends on workspace or product area, ask for that context in plain language. If the visitor needs a scheduled conversation, offer that purpose instead of forcing a technical category.

Useful first choices include:

• General service-desk question • Employee workspace or access question • Customer account or product question • Implementation or partner conversation • Vendor or delivery question • Something else for human review

These choices are routing hints, not diagnoses. A visitor may select the closest purpose and explain the details in their own words. Keep “something else” available so a person is not trapped by your taxonomy.

Ask for context visitors can safely provide

An effective intake usually needs a name, organization or workspace, purpose, and a short description. Explain why each field helps the host. “Which organization should we associate with this conversation?” is friendlier than an unexplained customer ID. “What would you like the service desk to understand first?” invites a concise summary without demanding a full incident report.

Do not request passwords, API keys, access tokens, private encryption material, or other secrets. Avoid asking a visitor to paste complete logs, customer records, or confidential incident details into a general reception. If your internal process requires sensitive evidence, orient the visitor to the approved secure channel and let the human owner give the next instruction.

The AI receptionist can ask follow-up questions from an approved set, but it should not invent fields merely because a message sounds technical. Keep the intake bounded. A short, relevant conversation is more useful than an exhaustive form that visitors abandon or answer inaccurately.

Route by role and presence

After intake, use employee roles and current presence to make ownership visible. An “internal workspace” inquiry might go to an employee-support role; a customer question might go to a customer-support role; an implementation inquiry might go to a partner or onboarding role. Names are optional when roles provide enough clarity. Keep the available roles current so a visitor does not select a person who no longer handles the request.

Presence states should describe reality. “Available for general questions” is different from “handling an active incident.” If no suitable person is present, put the request in the response queue and show an honest message about what the visitor can expect next. A queue assigns work; it does not create an SLA or guarantee response time, technical resolution, recovery, or uptime.

When a host accepts, preserve the intake context so the visitor is not asked to repeat their name, organization, purpose, and summary. The host can continue in chat or choose browser phone, video, screen sharing, or a private consultation room. The chosen destination depends on the human's judgment and the service desk's own information-handling rules.

Separate everyday questions from sensitive paths

General orientation and account-specific handling should not share the same implied promise. The AI can explain office hours, describe available purposes, and tell visitors how a human handoff works. For an account change, suspected compromise, recovery request, or security concern, the approved answer should state the boundary and point to the service desk's existing process.

If a visitor describes an urgent incident in the first message, do not let a friendly form imply that the inquiry is already in the incident queue. Acknowledge the purpose, avoid diagnosis, and tell the visitor which approved channel or human role handles urgency. Never claim to have inspected a system, opened a ticket, contacted an on-call engineer, or started recovery unless a human process has actually done so.

Make forms welcoming for different audiences

Employees may know internal terms, while customers and vendors may not. Use plain labels first and optional examples second. “What is the name of your workspace or service?” can include a short hint, but it should not require visitors to understand an internal product code. Let a person explain a nonstandard request in their own words.

Keep the form short enough for a visitor on a phone. Avoid asking the same identity question in several ways. If the visitor already introduced themselves to the AI receptionist, carry that context into the handoff. A concise summary gives the host a better starting point than a transcript full of repeated prompts.

Review intake quality with real conversations

Test the intake as an employee, customer, implementation partner, vendor, and an after-hours visitor. Confirm that each person can recognize the right purpose, skip irrelevant questions, and understand what happens next. Ask service-desk staff whether the resulting context is enough to choose an owner without promising an outcome.

Review a sample of queue items each week or support period. Look for repeated “something else” selections, visitors who choose the wrong audience, and questions that cause the AI to provide unsupported technical advice. Update purpose labels and approved answers from those observations. Retire a question if staff never use its answer; add one only when it changes routing or human preparation.

Do not turn intake metrics into unverified marketing claims. Counts of inquiries, queue age, or selected purposes may help your own planning, but they do not prove better service performance, security, recovery, compliance, or SLA adherence. Publish only claims your organization can define and verify independently.

FAQ

Is Kiguri inquiry intake a replacement for an IT ticketing system?

No. It is a visitor-facing reception and routing workflow. Keep the ticket, incident, change, and account systems that your service desk already owns.

How many fields should an intake form have?

Use the minimum needed for the next routing decision: usually identity, organization or workspace, purpose, and a short description. Add a field only when a human owner will act on its answer.

Can visitors submit credentials or logs?

They should not submit passwords, keys, tokens, or sensitive material to a general reception. Direct visitors to the approved secure process and let a human owner provide context-specific instructions.

Can the AI troubleshoot an outage?

Use approved general orientation only. The AI should not diagnose, inspect systems, promise recovery, or claim that an outage is resolved. Route incident-specific questions to the responsible human process.

What happens when no employee is available?

Keep the inquiry in a response queue and display an accurate availability message. Do not promise an immediate response or an SLA unless your organization has separately established and verified that commitment.

Is a private room proof of security or compliance?

No. A private room is a destination for a human conversation. Follow your own policies for access, sensitive information, retention, and regulated work.

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.