Capturing structured customer data with AI sounds simple: take a free-text message and turn it into fields in a CRM. In practice, the useful work is deciding what each field means, whether the customer actually supplied the information, which record should receive it, and what happens when the system is unsure. A small UK supplier can gain time from reliable extraction, but it can lose trust quickly if an inferred product code becomes an order or the wrong customer receives a reply. This guide explains a bounded workflow and compares two documented structured-output approaches rather than presenting a product ranking.
1. Define an enquiry schema around decisions, not convenience
Start with an actual business process. Imagine a trade supplier receiving emails asking about replacement components. A useful record might contain the source message identifier, sender address, company name as written, explicit product reference, quantity, stated delivery location, requested date and enquiry category. Each field needs a definition. Is quantity a whole number of units or packs? Can an account be identified by trading name alone? Does a delivery request mean a confirmed order? Document these questions before writing a prompt.
Separate mandatory fields from desirable ones. An enquiry may need only contact information and a description before a colleague can follow up. A CRM field marked mandatory for every record could force a model to invent a product code or make an assumption about geography. Allow null values for missing facts and create an explicit list of unresolved questions. A short, useful record is better than a complete-looking but fictional one.
Keep the original channel, timestamp and message link next to extracted values. Those are provenance anchors. Without them, staff cannot distinguish a mistake in extraction from a later change made by a colleague. Specify the data owner, retention requirement and who can inspect customer information before exposing messages to any AI service.
2. Distinguish extraction from classification and prediction
An email that says 'please send six units of SKU AX-42' contains directly expressed values. A system may still need to check that AX-42 exists and six means six units rather than six cases. A label such as 'high-value prospect' or 'urgent complaint' is different: it is an interpretation based on business definitions. Do not store both categories as equally verified facts.
Use distinct fields such as stated_product_code, suggested_enquiry_type and human_approved_status. Where the sender is ambiguous, capture the actual wording and request clarification. Inferred purchasing intent should not silently affect price, credit limits or eligibility. The UK Information Commissioner's Office guidance on AI accuracy distinguishes the accuracy of personal data from a model's statistical performance. That distinction is useful for everyday CRM design: technically plausible predictions do not become facts merely because they are formatted neatly.
Write examples of acceptable and unacceptable outputs. A direct quotation from an enquiry can support a factual extraction; an industry stereotype cannot justify a budget estimate. Review categories with sales and support staff because the same message may contain both a purchase request and a safety issue. Route complicated cases to a person, rather than forcing one label.
3. Use a defined JSON schema, then validate outside the model
Structured-output features can constrain the shape of a model response. OpenAI's Structured Outputs guide describes schema-constrained results, with supported schema features and documented limitations. Google's Gemini API structured-output documentation likewise explains JSON-schema-based output and its own supported subset. These mechanisms reduce malformed payloads, but they do not guarantee that the value 'AX-42' really appeared in the customer's message or corresponds to a valid product.
For a small pilot, define a field-by-field schema with explicit allowed categories and nullable missing values. Validate syntactic requirements outside the AI, then look up actual customer and product identifiers in authoritative systems. A parsed email address is not evidence that an account belongs to the sender. A delivery date written in the correct format is not evidence that the business can fulfil it.
Test refusal, incomplete output, invalid characters, prompt injection inside the customer message and a message containing multiple conflicting values. Do not ask the model to decide whether it has sufficient authority to modify the CRM. The receiving application should make that decision using deterministic rules and permissions.
4. Design the review and CRM write as separate stages
Make the first AI stage produce a proposed record, not an immediate production write. Display the proposed values beside the original enquiry and highlight nulls, ambiguity and inferred fields. For ordinary low-risk categories, staff can accept a group of fields together. For duplicate identities, pricing commitments, complaints or disputed information, require explicit review. Keep the record of who approved a change and what was altered.
Before creating a contact, search existing records using trusted identifiers such as a customer number or appropriately verified email domain and account relationship. Similar names are not enough for an automatic merge. When two possible matches remain, create a review task. If the system creates a draft lead, give it a provisional state and make it obvious it is not an authorised sales order.
Make downstream actions idempotent where possible: the same inbound message may be delivered twice after a timeout. A stable message ID, processing state and duplicate check reduce repeated tasks and duplicate records. Keep errors visible; staff should know what was processed, what failed and what needs manual recovery.
5. Compare vendor capabilities through the same customer scenario
A prompt-level demonstration is not a fair procurement test. Prepare an identical test set for both shortlisted structured-output APIs: clear enquiries, two conflicting product identifiers, a missing address, copied instructions intended to manipulate the assistant, a long message and one with sensitive information that should not enter the CRM. Evaluate whether each produces parseable data under its documented interface, then score the factual values against human-reviewed answers.
Track field-level correction rates and the time a reviewer actually spends. A solution producing many fields automatically can be worse than one producing fewer but more dependable fields. Check current provider processing policies, pricing, region options and integration effort as separate factors. Vendor documents describe features and constraints; they are not an independent accuracy benchmark for your enquiries.
6. Protect people and the source record
Personal data protection is not solved by producing valid JSON. Decide which data is necessary for the task, what lawful basis applies, which processor receives it and how long source text is retained. Avoid uploading an entire CRM or historic email archive to test a narrow extractor. Restrict credentials to the minimum read and write operations and do not let the model select arbitrary accounts or applications to access.
The ICO's guidance on accuracy and statistical accuracy is particularly relevant when fields are derived from personal information. Staff need a means to discover and correct inaccurate records. Record whether a value came directly from a customer, a lookup in a trusted system or a model-generated suggestion. That provenance is useful both for customer service and for handling a correction request.
Separate staff access by role. A support employee may need a ticket summary without permission to change account ownership, while finance may require additional checks for bank details. Human approval should be tied to the actual risk, not used as a cosmetic checkbox after the AI has already completed a consequential action.
7. Pilot for recovery, not merely successful extraction
Begin with one inbox and one destination, using synthetic or properly anonymised examples. Agree an expected record for each message and preserve a manual route. Run cases with a disconnected CRM, failed API request, duplicate email, previously closed complaint and ambiguous company name. A satisfactory result may be an exception task rather than a completed record. The system should not silently discard an enquiry because a model returned an invalid response.
Calculate cost using actual message volumes, model calls, integration maintenance, review time and exception handling. Measure both time saved and errors avoided. Track the fields staff repeatedly correct, then improve the field definitions or upstream form rather than continually changing prompts. Make logs searchable by message ID without unnecessarily exposing personal content.
Review the pilot with the staff who must use it every day. Can they understand the source, correct the proposed record, find an exception and explain what happened to a customer? If not, expanding automation will magnify confusion. A smaller controlled deployment is a legitimate successful result.
8. Decide when AI extraction is justified
Use fixed form fields when customers can readily supply the information. Use AI extraction when valuable details arrive in natural language and structured handling saves repeated interpretation. When the team struggles chiefly with duplicate CRM records or missing account identifiers, fix that data foundation first. A language model cannot convert uncertainty into verified identity.
Choose tools according to schema support, deployment fit, review controls and operational evidence rather than a broad claim about model intelligence. Keep the original enquiry available, validate critical fields with deterministic systems and require approval before consequential writes. That approach makes structured capture useful without turning an apparently tidy CRM into a record of unexamined guesses.
OpenAI or Gemini for extracting customer enquiry fields?
For a UK product supplier, the fairest comparison begins with the same enquiry samples, schema, correction policy and privacy requirements. Both APIs support structured output, but neither establishes that a model-generated company name or SKU is true. The choice depends on which documented constraints fit the actual application and which produces fewer mistakes in a measured pilot.
| Procurement test | OpenAI Structured Outputs | Google Gemini structured output |
|---|---|---|
| Schema approach | Use a supported JSON schema with documented strict structured-output behaviour; check model and schema compatibility. | Provide the supported JSON Schema subset; check for rejected complexity or ignored constraints. |
| Missing customer detail | Define a permitted null or explicit unresolved value and verify the result against the source email. | Use the documented nullable types and verify that a missing value was not guessed. |
| Constraint limitation | Check supported schema features, model eligibility and refusal or incomplete-response handling. | Do not rely on unsupported or unenforced constraints such as minLength; validate them in the application. |
| Product and account identity | Validate proposed SKU and customer ID against authoritative catalogue and CRM data. | Apply the same external identity and SKU lookups; schema validity is not factual verification. |
| Pilot evidence | Measure factual field errors, exception rate, staff corrections and cost on protected examples. | Run the identical examples and measures; no assumed winner from vendor documentation. |
| When to favour | When supported schema features, integration and independently checked accuracy best fit the workflow. | When its supported schema subset, deployment conditions and measured outputs better meet the same tests. |
Who should choose which? If strict schema features supported by the chosen OpenAI model simplify integration and the pilot confirms accurate values, that is a reason to favour OpenAI. If Gemini's supported subset covers the fields and a same-case test shows an equivalent or better operational result, Gemini is a sound alternative. Neither is automatically better. Source A: OpenAI Structured Outputs, product documentation (supported schemas and response handling; vendor documentation, not an external accuracy benchmark). Source B: Google Gemini API structured-output documentation (supported JSON Schema subset and limitations; vendor documentation, not an independent test). UK personal-data context: Information Commissioner's Office AI and data-protection guidance. Validate source messages, permissions and CRM writes independently of either model.
Frequently Asked Questions
Which customer-data fields should a small team automate first?
Start with a small set of fields that staff genuinely use and that can be supported by the source enquiry, such as contact details, organisation, enquiry type or stated product interest. There is no universal five-to-eight-field target; scope should reflect the workflow and the consequence of errors.
What should remain subject to human confirmation?
Use stronger review where extracted or inferred information could affect pricing, eligibility, contractual treatment, compliance or another consequential decision. The appropriate control depends on the business process and the reliability of the underlying evidence.
How should capture quality be measured?
Track correction patterns, duplicate creation, missing important fields and whether the receiving team can act without repeatedly returning to the original enquiry. Keep the source material available so uncertain classifications or extracted facts can be checked.
How should the workflow be maintained?
Review exceptions and repeated corrections, then adjust field definitions, prompts or validation rules when evidence shows a recurring problem. Use a cadence appropriate to volume and risk rather than assuming one fixed maintenance schedule.