Confirmation response parsing

An NLP classifier reads the inbound confirmation reply as free text, maps it to confirmed, rejected, or ambiguous, and writes that state onto the task record. Coordinators then see whether the ask landed without opening every thread and interpreting the language by hand.

The model is a mapper, not a closer. It does not approve work, cancel a booking, send a counter-offer, or notify a requester. It interprets a message that already arrived and stores a structured result. People still own what happens after a reject and after any label the model cannot place cleanly.

Typical inputs are email bodies, chat messages, SMS, and ticket comments. The text is often short, idiomatic, and tangled with quotes from the outbound request. Classify the latest human reply, not the quoted ask, not the signature block, and not an earlier message in the same thread unless your pipeline explicitly concatenates a bounded window.

Speed on this outcome comes from removing the read-and-file step. The queue can sort on state as soon as a parse completes: confirmed ready to proceed, rejected ready for exception handling, ambiguous ready for a human read, and unparsed items left in their prior state.

Confirmed is a clear acceptance of the pending request as posed. Informal wording still counts when it attaches to that request: yes, confirmed, looks good, proceed, we can do that time, that works. The acceptance must answer the open confirmation, not an unrelated aside in the same thread.

Rejected is a clear refusal of that request: no, we cannot do that, cancel it, that slot does not work, please find someone else. Treat rejected as a status on the record. Do not treat it as an automatic next action. A person still chooses whether to re-ask, substitute, or close, because a "no" is sometimes about a detail (time, quantity, location) rather than the whole job.

Ambiguous is linguistically parseable text that is still not a clean yes or no. That includes questions, counter-proposals, "maybe", "let me check", acceptances that name a different date or quantity, and mixed messages such as "Thursday is fine but not the morning slot." Ambiguous is a real operational state. It is not a failed run. It is the label that tells staff the reply needs a human read before the task can move.

When the request has multiple line items and the reply is mixed ("yes to A, no to B"), do not stamp confirmed. Unless a dedicated detector has already split the ask into items, file the reply as ambiguous. Partial confirmation detection is the adjacent workflow when mixed item-level yes and no should be first-class outcomes rather than a single ambiguous flag.

When the text is clearly a question about the request rather than an answer, prefer ambiguous over confirmed. A reply that only asks "which warehouse?" or "is this still for Friday?" has not accepted the original terms.

Return empty output when there is not enough reply text to justify a state. Empty is different from ambiguous. Ambiguous means the classifier read usable language and still could not resolve yes or no. Empty means there was nothing reliable to read.

Thin inputs include blank bodies, signature-only messages, attachments with no caption, "See below" with nothing below, out-of-office templates, and threads where the latest item is an image or a forwarded header with no new sentence. If the extractor cannot find a usable span of reply text, do not guess confirmed, and do not guess rejected.

Empty output leaves the task in its prior confirmation state. It does not stamp ambiguous. Labeling silence or a hollow body as ambiguous would send coordinators into clarification work that has no human sentence to clarify.

If nobody replied at all, that is not a parse problem. There is no text for this classifier to map. Non-response escalation trigger is the workflow that watches the clock when a confirmation request stays unanswered.

If a later message in the same thread contains real text, run the classifier again on that message. An empty result on the first bounce does not block a later confirmed, rejected, or ambiguous label.

Very short tokens need the same honesty. A lone "OK" or "k" after a long thread might accept the last question, not the original booking. If the pipeline cannot attach that token to the open confirmation with any confidence, empty output is the correct result. Spot-check confirmed labels on the shortest replies; over-trusting them is the usual failure mode.

A successful parse should update the task with the mapped state (confirmed, rejected, or ambiguous), a pointer to the source message, a timestamp, and enough of the classified span that a coordinator can see why the label was chosen without opening the full thread. Store the raw reply or a truncated excerpt next to the state.

Do not overwrite an existing confirmed or rejected state with empty output from a later thin message. Empty means "no new parse," not "clear the status."

If the same task receives two substantive replies, define which label wins before you go live. The usual operations rule is: confirmed and rejected stay until a person changes them; a later ambiguous reply can add a note or a flag without silently unconfirming. Coordinators should know which rule their queue uses, because a second message that says "wait, actually Thursday is better" is a real change in intent and still should not be applied as a silent unconfirm unless a human accepts that reversal.

Do not auto-close the task on confirmed. Confirmation of the ask is not completion of the work. Do not auto-close on rejected either. A reject usually starts an exception path: reassign, rebook, or tell the requester the original slot no longer holds.

The record is there so the queue can move. Confirmed items proceed. Rejected items enter exception handling. Ambiguous items wait for a person. Empty items stay where they were until a real reply arrives or silence is escalated.

Human-in-the-loop is required on this outcome. The classifier maps the reply. Staff still handle rejects and remaining ambiguity.

On a reject, someone chooses the next action, records who was informed, and keeps the requester from assuming the original slot still holds. Mapping "no" straight into a cancelled task without a person in the loop hides misses when the refusal was partial, joking, or about a side question in the thread.

On ambiguous, a coordinator (or a clarification workflow they start) must read the reply before the task moves. Do not treat ambiguous as a soft confirmed in order to keep the queue green. Ambiguous reply clarification is the follow-on when the reply is a question or a counter-proposal and the next step is a structured ask, not a status guess.

Staff also sample the confirmed bucket. Confirmation language is short and easy to overfit. If a short reply is too thin to trust, empty output is correct even when a person might infer that "OK" means yes.

The daily motion for an operations coordinator is narrow: scan confirmed for anything that looks attached to the wrong ask, work rejects as exceptions, open ambiguous items, and leave empty results alone until a real reply shows up or a non-response rule fires.

Use this parser when a reply exists and the job is to file it as confirmed, rejected, or ambiguous. Use Partial confirmation detection when the request has multiple items and a mixed yes and no should be stored as a partial result. Use Ambiguous reply clarification after this classifier has already marked ambiguous and someone needs a follow-up question. Use Non-response escalation trigger when there is no reply to parse.

Do not run clarification prompts on empty output. There is no content to clarify. Do not escalate silence solely because a signature-only message produced empty; decide first whether a human actually responded.

The operational contract is narrow on purpose. Parse the reply. Write the state. Leave rejects and ambiguity with staff. Return nothing when the text is too thin. That takes confirmation filing off the critical path without pretending the model closed the loop.