A sturdier design separates two jobs: first extract and validate the request into a structured record, then let anything downstream (a human, a template, or an agent) work from that record. This post shows a small, testable intake layer in Python using Pydantic, with the rules we found matter most for small export desks.

Why extraction should be its own stage

When extraction and drafting happen in one prompt, you can't tell why a reply went wrong. Did the model misread "5k pcs" or did it make up a lead time? If you split the stages:

• You can unit-test extraction against real (anonymised) emails.
• You can block drafting when required fields are missing, instead of letting a model guess.
• You get a clean dataset of what buyers actually ask for, which is useful long after the AI project.

The extraction step can be regex, an LLM with structured output, or both. What matters is that its output passes a strict schema before anything else runs.

Step 1: Define the record you actually need

Resist the urge to capture everything. For a first-pass quote, most desks need about eight fields:

from datetime import date
from enum import Enum
from typing import Optional
from pydantic import BaseModel, Field, field_validator

class Incoterm(str, Enum):
    EXW = "EXW"; FOB = "FOB"; CIF = "CIF"; DAP = "DAP"; DDP = "DDP"

class RFQ(BaseModel):
    buyer_email: str
    buyer_company: Optional[str] = None
    product_ref: str = Field(min_length=2)          # SKU or product name as written
    quantity: int = Field(gt=0)
    unit: str = "pcs"
    incoterm: Optional[Incoterm] = None
    destination_country: Optional[str] = None       # ISO 3166 alpha-2
    target_date: Optional[date] = None
    raw_excerpt: str                                 # the sentence(s) the values came from

    @field_validator("destination_country")
    @classmethod
    def iso2(cls, v):
        if v is not None and (len(v) != 2 or not v.isalpha()):
            raise ValueError("use ISO 3166 alpha-2, e.g. 'DE'")
        return v.upper() if v else v

Two choices worth copying. raw_excerpt forces the extractor to show its evidence, so a reviewer can check a value in seconds. And optional fields stay None rather than getting a default. A missing Incoterm is information. A defaulted "FOB" is a silent commitment.

Step 2: Normalise quantities before validating

Buyers write "5k", "5,000 pieces", "2 x 40HQ" or "MOQ?". Normalise the common cases yourself and send everything else to review rather than to a model's best guess:

import re

_QTY = re.compile(r"(?P<n>\d+(?:[.,]\d+)?)\s*(?P<k>k)?\s*(?P<unit>pcs|pieces|units|sets|cartons)?", re.I)

def parse_quantity(text: str) -> tuple[int, str] | None:
    m = _QTY.search(text)
    if not m:
        return None
    n = float(m["n"].replace(",", ""))
    if m["k"]:
        n *= 1000
    unit = (m["unit"] or "pcs").lower()
    unit = {"pieces": "pcs", "units": "pcs"}.get(unit, unit)
    return int(n), unit

Container-based quantities ("2 x 40HQ") are deliberately not handled here. Converting them depends on carton size and product, and that belongs with a person who knows the packing list.

Step 3: Validate, then route on what's missing

Validation shouldn't just pass or fail. It should tell you what to do next:

from pydantic import ValidationError

REQUIRED_FOR_QUOTE = {"incoterm", "destination_country"}

def route(candidate: dict) -> tuple[str, RFQ | None, list[str]]:
    try:
        rfq = RFQ(**candidate)
    except ValidationError as e:
        return "reject_to_human", None, [err["loc"][0] for err in e.errors()]
    missing = [f for f in REQUIRED_FOR_QUOTE if getattr(rfq, f) is None]
    if missing:
        return "ask_buyer", rfq, missing      # send a clarifying question, not a price
    return "ready_for_quote", rfq, []

Three outcomes, three different queues. The ask_buyer path is the one people skip, and it's the most valuable. A short "Could you confirm the delivery terms (FOB or CIF) and destination port?" is safe to send automatically, because it commits you to nothing.

Step 4: Deduplicate repeat requests

The same buyer often sends the same RFQ through a marketplace inbox, then by email, then on WhatsApp. Without a dedup key, two people quote the same job at different prices. A simple fingerprint is usually enough:

import hashlib

def fingerprint(rfq: RFQ) -> str:
    key = f"{rfq.buyer_email.lower()}|{rfq.product_ref.lower().strip()}|{rfq.quantity // 100}"
    return hashlib.sha256(key.encode()).hexdigest()[:16]

Bucketing quantity to the nearest hundred catches "5,000" vs "5,050" without merging truly different orders. Store fingerprints with a 14-day window and attach new messages to the existing thread instead of opening a new one.

Step 5: Test against real emails

Collect 30 to 50 anonymised RFQs and write expected records for each by hand. That fixture set is your regression suite:

import json, pytest

CASES = json.load(open("fixtures/rfqs.json"))

@pytest.mark.parametrize("case", CASES, ids=lambda c: c["id"])
def test_route(case):
    decision, _, missing = route(case["extracted"])
    assert decision == case["expected_decision"]
    assert set(missing) == set(case["expected_missing"])

When you swap extraction methods (regex to LLM, or one model to another), this suite tells you right away whether routing got better or worse. That beats eyeballing a few replies.

Where this fits in a real workflow

On marketplace seller accounts, such as Alibaba.com storefronts run by small Hong Kong export teams, this intake layer usually sits between the platform inbox and whatever drafts replies. If you're evaluating AI reply agents for that setting, it's worth checking how they handle missing fields. Some vendor overviews, like this one on Accio Work for Alibaba.com sellers, describe the agent side, but the validation contract is still yours to own.

Before go-live, write down which fields your desk treats as required, who owns the reject_to_human queue, and how long the dedup window is. A plain pre-launch checklist helps keep those decisions out of people's heads and in a shared document.

Takeaways

• Extract into a strict schema first. Draft second.
• Keep missing values as None. Defaults are commitments.
• Route on what's missing. A clarifying question is the safest message you can automate.
• Fingerprint RFQs so a request that arrives through several channels gets one quote.
• Keep a fixture suite of real emails and run it every time you change the extractor.

None of this needs a large model or a big platform. It's a hundred or so lines of boring, testable code, and it makes whatever AI you add later much easier to trust.