Conversational slot-filling intake

Support ops leads adopt this for one reason. Tickets arrive missing the facts an agent needs, and the first reply becomes a request for information. A slot-filling intake agent closes that gap while the customer is still in the conversation. It asks for the missing pieces, then hands over a ticket with the required fields populated.

What it produces is a structured record. Issue type, product area, environment, affected identifier, timestamps, and whatever else the schema demands. Each field carries the customer's own answer. The agent does not diagnose, does not promise a fix, and does not set priority.

That boundary matters. A bot that collects an order number has done its job. A bot that tells the customer their refund is approved has made a commitment nobody authorized.

Fin and Ada sit in this category, alongside the native intake bots in most helpdesk suites. They differ in how they branch and where they write. None of them knows which fields a given team actually needs. That list belongs to the support org.

Downstream work depends on it. Intent and category classification performs better on a ticket with five clean fields than on a paragraph of prose.

Write the field set per issue type, not per team. A billing dispute and a login failure need almost nothing in common. One needs an invoice number and a charge date. The other needs a username, a browser, and an error string.

Keep each list short. Four to six required fields is a practical ceiling for most issue types. Anything the system can look up should not be a question. If the customer is signed in, do not ask for their email.

Mark each field as required, optional, or derived. Required means the ticket cannot submit without it. Optional means ask once and move on. Derived means the system fills it from session data, account records, or the page the customer was on.

Write the validation rules alongside the fields. An invoice number has a shape. A date has a range. A version string belongs to a known list. Without rules, the bot accepts "the new one" as a version, and the agent is back where they started.

If no field set exists for the issue type the customer picked, the bot should collect a free-text description and stop. A guessed set of questions is worse than none. It teaches customers that the questions are noise.

Parse the opening message first. Most customers volunteer two or three slots without being asked. "My invoice 4471 charged twice on Monday" fills the issue type, the invoice number, and an approximate date. Asking for those again is the fastest way to lose the person.

Then ask only for what is still empty. One question per turn. Bundled questions get partial answers, and partial answers are hard to map back to fields.

Every answer needs to land in a named slot. If a reply does not parse into the field that was asked for, ask once more in plainer words. If the second answer still does not parse, store the raw text in a notes field and move on. Two failed attempts on one slot is the point to stop.

Order questions by how much they change the routing. Issue type first. Then the identifier that lets an agent look something up. Then the detail that narrows the cause. A customer who abandons after three turns should still leave behind a routable ticket.

Confirm before submission. Show the filled set in plain language and let them correct it. That step catches transposed order numbers, which are common and expensive.

Here is a hypothetical walkthrough. A payroll software vendor supports mid-sized employers across three countries. A finance manager opens the widget and types that payroll did not run this morning.

The opening message fills one slot: issue type, payroll run failure. The required set for this type has six fields. Legal entity, pay run identifier, scheduled pay date, error message shown, number of employees affected, and whether any payments already left the account.

The bot derives two of them. The signed-in user belongs to one company with two registered entities, and the session names which entity's dashboard she was on. Scheduled pay date comes from the run calendar. Four questions remain.

Question one asks for the pay run identifier and offers the three most recent runs as choices. She picks the Friday run. Question two asks what the screen said. She pastes an error string. Question three asks roughly how many employees are on the run. She answers 240. Question four asks whether any payments have already been sent. She does not know.

That last answer is the useful one. The bot does not guess. It writes "customer unsure" into the field, flags it, and submits. The ticket arrives with five fields filled, one marked unknown, and the transcript attached. The agent who picks it up knows to check payment status first, because that field is the one that decides urgency.

Compare that with the version that arrives as "payroll broken, please call." Same customer, same problem, and a working day lost to a reply asking which run.

Four things break this pattern, and each shows up as abandonment first.

Too many questions. Each additional turn is another chance for the customer to give up. Teams add fields because an analyst wants them, not because an agent needs them. Audit the field set against what agents actually open, then cut anything nobody reads.

Filled fields that were never asked. A bot can infer the product area from wording. Writing that inference into a required field, as if the customer said it, manufactures a fact. Store inferred values in a separate column and label them inferred.

Ignoring what the customer already said. Nothing erodes trust faster than being asked for an order number in the same breath you supplied it. Parse first, ask second.

Blocking on a field the customer cannot know. Version numbers, account IDs, and internal error codes are often invisible to the person reporting. Every required field needs an escape route: a "not sure" option that submits the ticket with the slot empty and a note explaining why.

Angry customers are their own case. Someone who has already typed three furious sentences should not meet a form. Detect that and route to a person. Sentiment-driven priority scoring is the downstream check, but the bot needs its own bail-out at intake.

Filled fields are a starting position, not a verdict. The agent reads the transcript, not just the summary row, and can overwrite any field the bot populated. Slots the customer skipped stay empty and visible, because an empty field is a question the agent should ask.

Nothing the bot collected should trigger an action on its own. A refund amount sitting in a slot is a claim about what happened, not an approval. Automated action belongs downstream, under separate control, as in an autonomous resolution agent with its own spending limits.

Priority stays with triage. A customer stating that the issue is urgent fills a field. It does not set the queue position. Keep stated urgency and assigned priority in two different columns, or the first will quietly become the second.

Review the field sets monthly. Pull the tickets where an agent's first reply still asked for information. Each one names a missing slot or a question the bot phrased badly. That list, not a completion rate, tells the ops lead what to change. Feed the same review into ticket resolution summarization so the fields that mattered at close become the ones required at intake.