A prospective customer sends a perfectly human inquiry: they want help with their website, possibly after their current contract ends, and their colleague may handle the budget.
The CRM would prefer a service category, a start date, a budget and a decision-maker. AI can help translate between those two worlds, provided we don’t ask it to manufacture the missing pieces.
Structured extraction turns free-form language into fields an application can process. OpenAI’s Structured Outputs, introduced in August 2024, supports responses matching a specified schema in supported configurations.1 That helps with predictable structure. It does not establish that every value extracted is correct.
Think of it as a well-designed set of drawers. Everything can fit neatly while the passport is still in the cutlery drawer. Organization and accuracy are related ambitions, but they need separate checks.
For a fictional agency, the first task is to define what each field means. A target start date, a contract expiry date and a preferred first-call date should not all become “date” because there is one available column.
The same care applies to budget. “We haven’t agreed a budget” is information. Converting it to zero changes its meaning. Converting it to a plausible amount changes the inquiry into a creative-writing exercise.
A useful extraction policy might specify:
- Keep a field unknown when the source does not establish its value.
- Preserve the original wording for ambiguous timing or budget information.
- Distinguish a stated fact from a proposed classification.
- Require review before overwriting an existing verified contact detail.
Those choices belong in the data model, validation and review process. A prompt can describe them, but the application also needs to enforce the rules that must hold.
See how we connected Mansa Medical’s website to its CRM to support an organised sales process.
Show staff what the model actually found
For our sample inquiry, the model might suggest “website project” as a category and leave the start date unresolved. It could preserve the sentence about the current contract so the person following up can ask the right question.
That is useful work. It prepares the conversation without pretending the conversation has already happened.
Validate the extracted values with ordinary checks. Does the email have a valid format? Does the proposed service category exist? Does the referenced company match a real CRM record? Format checks and lookups can catch different errors from those that require human interpretation.
Be particularly careful with merging records. Two similar company names or one shared email address are not necessarily enough to conclude that two inquiries belong to the same person. Let an uncertain match become a review task.
Pairs well with Before giving AI access to the CRM, draw the permission boxes.
Then evaluate the system on examples that reflect the actual messiness of incoming messages. Include conflicting dates, forwarded email chains, missing budgets and people contacting the business on somebody else’s behalf.
Hamel Husain’s evaluation writing is useful background for turning those failures into explicit checks.3 If a model is used to help judge extraction quality, compare its judgments with people who understand the CRM’s purpose. Otherwise one model can confidently congratulate another for a tidy mistake.
I would start by showing suggested fields beside the original message and letting staff confirm or correct them. Those corrections can reveal which definitions need work before more updates happen automatically.
The result should be less copying and a better-prepared follow-up. A slightly incomplete record that tells the truth is a much better colleague than a beautifully complete one that has filled the gaps with vibes.