Free-text request parsing

The job is a complete, editable requisition from messy intake. Chat, email, or a form's free-text box becomes category, item, quantity, need-by date, cost center, a budget figure or band, and an urgency flag. The requester still has to confirm category, budget, and urgency before the request routes.

A parse is not an approval. A parse is not a purchase order. If the system files a guessed PO from a Slack line, you skipped intake, policy, and a human in one move.

Speed here is the gap between "I need something" and a card the requester can correct in one pass. It is not time-to-PO.

Intake already lives in Zip, Coupa, ServiceNow, or in Teams and Outlook where Microsoft Copilot sits. Treat those as the channel, not as a ranked list of parsers. Draft against your requisition schema. Prefer blanks to invented SKUs.

Collect the raw message. Do not require the requester to know UNSPSC, your catalog, or the cost-center string. Then extract only the fields you already collect on the form.

How you gather the source text matters as much as the model:

• Chat. Take the thread, not the last bubble. People add "also the dock" two messages later. Cap the window so an unrelated conversation does not become line items.

• Email. Strip signatures, legal footers, and the copied chain. A title in a signature is not the cost-center owner. A thread summary is still not a requisition. Pipe the cleaned text into the same parser.

• Form free text. Parse the comment box together with any structured fields already filled. Do not OCR a long attachment and treat it as the request.

Map into these fields, and leave a field blank when the text does not support it:

• Category. Your taxonomy, not a generic goods list. If the model is unsure, leave it blank and ask. Do not silently pick "IT Hardware" because the word "laptop" appeared.
• Item. A plain-language description first. A catalog match is a suggestion, labeled as such, with an easy reject. Never write a SKU the requester did not accept.
• Quantity. Default to 1 only when the text is clearly singular. "Laptops for the new team" is not 1.
• Need-by. A calendar date. "ASAP," "this week," and "for the new hire" are not dates. Map them to a policy default or leave the field empty.
• Cost center. A starting value from the requester's org mapping is fine. It is still a guess until they confirm.
• Budget. Take a number only if the text states one. Otherwise leave blank, or show a band from policy as a hint, not a filled amount.
• Urgency. Separate from need-by. A Monday start date is a date. Calling it "critical" is a policy call the requester or intake analyst still makes.

Show the requester a structured card with every field editable. Put the original text on the card so they can see what was parsed. Require an explicit confirm on category, budget, and urgency. "Not sure" is a valid submit back to the intake analyst. Auto-submit is not.

If you also run spend category auto-classification, keep the jobs distinct. Parsing fills the request. Classification assigns the taxonomy code used for spend reporting. A wrong category on the card will train the classifier on junk.

Three failure modes show up as soon as the card looks complete.

The catalog item is wrong. "Laptop for new hire" matches the standard 14-inch build, but the hiring manager meant a CAD workstation, a rugged tablet, or a Mac that is not on the preferred SKU. The parser is optimizing for the most common historical laptop, not for this sentence. If you pre-select a catalog row, the requester will often click through. Label catalog matches as suggestions. Require a tap to accept. If the description includes dock, monitor, software, or "workstation," split lines or send to an analyst instead of forcing one SKU.

A capital request is routed as a laptop. Language like "new hire," "computer," or "setup" can hide a mill, a vehicle, lab equipment, or a facilities fit-out. Category and budget then follow the laptop path: IT approver, laptop threshold, preferred OEM. Guard with amount above the IT accessory threshold, words that are not IT (install, floor, plant, construction, leasehold), and any need-by that looks like a project milestone. When those fire, hold the card in an analyst queue. Do not let risk-based approval routing see a laptop category it will fast-track.

The parse is treated as already approved. A tidy card invites people to skip confirmation, skip policy, and skip the approver. Hard rule: parsed fields cannot create a PO. PO auto-generation from requisition starts from an approved requisition, not from a draft card. Confirmation is a recorded action by the requester, or by intake on their behalf with the requester's name still on the confirm.

A clean parse of a non-contract supplier is still maverick spend. Parsing does not choose the vendor of record. Run off-contract spend prediction after the card is confirmed, not against the raw sentence.

The following is a made-up but realistic intake, not a case study and not reported results.

A plant engineering manager DMs procurement intake: "need a laptop for new hire starting Monday, plus the dock, and the CAD box we talked about for the floor."

A naive parse returns one line: category IT Hardware / Laptops, item "standard laptop," quantity 1, need-by next Monday, cost center of the manager, budget blank, urgency high. If catalog matching is on, it pre-selects the preferred 14-inch Windows SKU.

What the message actually contains:

1. A possible laptop for onboarding, maybe the standard SKU, maybe not.
2. A dock, which is a second line or an accessory kit, not "quantity 1 laptop."
3. "CAD box for the floor," which may be a workstation, an industrial PC, or capital equipment on the plant floor. That is not the laptop catalog.

What intake should show, in one card with three proposed lines, all still drafts:

• Line 1: item "laptop for new hire," category pending confirm, qty 1, need-by the Monday date if the calendar can resolve it, cost center prefilled from HR, budget empty, catalog suggestion visible and unselected.
• Line 2: item "dock," qty 1, same need-by, no catalog row until they pick.
• Line 3: item "CAD workstation / floor" with category unassigned, a flag that this may be capital or plant equipment, and a note that intake will not route it as a laptop.

The manager must confirm or reject each line's category, budget, and urgency. If they only wanted one rugged laptop, they delete the extra lines. If "CAD box" is a controller for the line, it stays out of the laptop path.

If this card auto-submitted, Monday's new hire might get the wrong machine, the dock might never be ordered, and a capital buy might hit the IT laptop approver.

Ship this as a draft-filler in the channel you already use. The structured card is a proposal until the requester confirms.

Before you turn it on for a category, replay a sample of closed free-text requests against the parser. Score field by field: category, item, qty, need-by, cost center. A wrong category or a forced SKU is a fail even if the description looks fluent. Decide which fields may prefill. Catalog SKU and budget amount should start blank more often than category and cost center. Name who owns exceptions: intake analyst for split lines and capital suspects, requester for confirm, category manager when the taxonomy will not fit.

After confirm, run policy pre-check at intake before an approver sees the request. Classify from the confirmed description, not the raw Slack line. Check off-contract and routing on the confirmed category and amount, not on the model's first guess. Only then is PO generation in play.

If requesters stop editing category, budget, and urgency because the card looks finished, you have a speed win on paper and a controls problem in the ledger.