Unstructured request parsing

Inbound operations mail and tickets rarely arrive as clean forms. Requesters write in prose: a short paragraph about a broken printer, a forwarded thread about a vendor portal outage, or a chat dump pasted into the help desk. Unstructured request parsing uses a language model to read that free text and fill a fixed intake schema (request type, requester identity, urgency, affected system, and related fields your queue already expects) so the first human touch starts from a populated record instead of a blank form.

The model does not open the ticket, assign an owner, or decide priority policy. It proposes field values. An intake lead or triage agent reviews those values, corrects misses, and confirms the record before anything downstream runs. When the source text is too thin to support confident extraction, the system returns an empty or explicitly incomplete parse rather than inventing values.

Related intake steps that often sit next to this one: Auto-classification by type, Duplicate request detection, and Knowledge base match at intake.

Start with the fields your routing and SLA logic already depend on. Typical first-pass schemas for operations intake include:

• Request type or category label aligned to your taxonomy (access, incident, change, facilities, vendor, other).
• Requester as a person or mailbox, plus optional department or cost center when the text names them.
• Urgency or impact language mapped to your existing severity scale, not a new scale invented by the model.
• Affected system, service, location, or asset identifier when present.
• Requested action in one short phrase (reset access, investigate outage, schedule repair).
• Deadline or window only when the text states one; leave blank otherwise.
• Attachments or references called out in the body (ticket IDs, order numbers, screenshots mentioned but not yet linked).

Keep the schema small. Every extra optional field raises the chance of hallucinated filler when the email is vague. Prefer null, empty string, or an explicit insufficient_evidence flag over a guessed value.

Map model output to your ticket system field names one-to-one. If your CMS or ITSM tool uses impact and urgency separately, ask for both only when your playbooks already distinguish them; otherwise extract a single priority hint and let staff finalize.

1. Capture source text. Pull the email body, chat transcript, or free-text ticket description. Strip signatures and legal footers when they drown the signal, but keep quoted history if the latest message alone is incomplete.
2. Run extraction against a fixed JSON (or form) schema. Constrain the model to your enum values for type and urgency. Require structured output so downstream code does not scrape free-form prose.
3. Score confidence per field or overall. Use model logprobs, a second pass that cites spans, or a simple rule: if the supporting span is missing, the field stays empty.
4. Present a side-by-side review. Show original text, highlighted spans used as evidence, and proposed field values. The intake lead edits anything wrong in the same screen used for manual intake.
5. Confirm, then hand off. Only after confirmation does classification, duplicate checks, or knowledge-base matching consume the record. Treat unconfirmed extractions as drafts, never as live tickets.

Human confirmation is mandatory for production intake. Models misread sarcasm, internal jargon, and multi-party threads. Staff remain accountable for the record that opens the queue.

Not every message contains enough signal. Examples that should yield empty or partial output:

• Subject-only tickets with no body.
• Single-line messages such as “help” or “see attached” with no attachment context in the text.
• Forwarded digests where the actionable ask is missing.
• Multilingual fragments your prompt does not cover, until you add language support deliberately.

Policy for thin input:

• Return an empty object, or a record with all critical fields null and a machine-readable reason (text_too_short, no_actionable_request, ambiguous_requester).
• Do not default urgency to “medium” or type to “general” to look complete.
• Surface the empty result to the intake lead as “needs manual entry,” not as a successful parse.
• Optionally queue a short clarifying reply template for staff to send; do not auto-send without approval.

Empty output is a feature. It protects SLA clocks and routing from false confidence.

Schema-first prompts. Describe each field, allowed enums, and the rule “leave blank if not supported by the text.” Include two or three short examples from your own anonymized tickets, not generic internet samples.

Span grounding. Ask the model to return, for each filled field, a short quote or character range from the source. Reject fills whose quote does not appear in the input.

Normalization after extract. Map free-text system names to your CMDB aliases with a deterministic dictionary (“ADP” → HR payroll service ID). Keep fuzzy matching out of the LLM step when a lookup table exists.

Idempotency. Re-running extraction on the same body plus schema version should produce the same structure. Version the prompt and schema so you can audit drift when you change either.

PII handling. Requester names, phone numbers, and account IDs often appear in tickets. Keep extraction inside your approved data path, redact fields your policy forbids from model logs, and limit retention of raw prompts to what operations already allows for ticket content.

Eval set. Maintain a small labeled set of real (anonymized) tickets with gold fields. Measure field-level precision and recall, plus “empty when thin” accuracy. Promote prompt or model changes only when empty-case behavior does not regress.

Unstructured parsing is usually the first enrichment step after a channel lands in the queue. A practical order:

1. Parse free text into a draft intake record (this page).
2. Auto-classify by type if type was left open or needs a finer taxonomy.
3. Detect duplicate requests using structured fields plus embeddings on the description.
4. Match knowledge base articles at intake once type and system are confirmed.

Skipping confirmation before those steps amplifies errors: a wrong system name sends duplicate detection and KB matching down the wrong branch. Keep the human gate between draft extraction and automated follow-on.

Operational success looks like shorter time-to-first-structured-record, fewer blank required fields at assignment, and fewer reopenings caused by mis-typed urgency or system. Measure those process metrics on confirmed records. Do not treat raw model fill rate as the goal; treat confirmed, accurate intake as the goal.