The problem AI solves here
Customers write however they write.
“Do you have the 40mm brackets, need about 200, and the mounting kits too”
“printer on floor 2 showing error again 😩”
“hi is my order shipped yet, ref 4471”
None of that is structured data. No rule handles it — keyword matching breaks on how people actually type, and every customer phrases things differently.
This is the one place in a WhatsApp workflow where a model genuinely earns its place. Everything else is ordinary logic.
What it can extract
Four useful outputs.
Intent. Is this an order enquiry, a support problem, a delivery question, a complaint?
Entities. Products, quantities, order references, dates, locations.
A structured summary. For a support ticket or a note on a record.
A suggested category or priority. As a suggestion, not a decision.
The rule for all four: ask for structured output, not prose. A list the next step can work with, not a paragraph.
FIGURE 1: FROM MESSAGE TO ACTION
Message arrives
- Free text, however they wrote it
Model extracts
- Intent and entities, as structured data
Systems searched
- Match to real records
Action prepared
- For a person to confirm
The step that matters most
Extraction is not matching.
A model can tell you the customer said “40mm brackets”. That is not a product. It has to become a specific record in your system.
Search your system for it. Three outcomes, and each needs a decision made in advance:
One clear match. Use it.
Several possible matches. Do not guess. Ask the customer which, or hand to a person.
No match. Say so, or escalate.
This is where most of the risk sits. A model can produce a plausible product name that does not exist, and quietly matching it to the nearest thing is how a customer receives a quotation for the wrong item.
Fail visibly rather than guessing.
Matching the customer
By phone number — you have it, since they messaged you.
Which means phone numbers must be stored consistently in your business system. Country code included, no spaces or punctuation.
Inconsistent formatting is the most common cause of a customer not being found and a duplicate being created.
And decide what happens for an unknown sender before go-live, not when the first one arrives.
Handling media
Messages arrive with photos, screenshots and voice notes.
Three things to handle:
Download it. The message references the media; you have to fetch it.
Attach it to whatever you create. A photo of a broken part is often the most useful thing in a report.
Handle the case where it is the only content. Somebody sends a photo with no text. Ask them to describe it, or create the record with the image and a note that no description was given — but decide which.
Where the human stays
Three lines that do not move.
Anything commercial. A quotation is a commercial document. The workflow assembles it; a person confirms and sends.
Anything sent to a customer unread. Generated text is fluent whether or not it is correct.
Priority that skips a queue. A model reading urgency from tone overrates a politely worded serious problem and underrates an angry trivial one. Suggest, do not set.
FIGURE 2: WHAT THE MODEL DOES AND DOES NOT
The model does
- Reads the message however it was written
- Extracts products, quantities, references
- Suggests a category or priority
- Drafts a structured summary
A person does
- Confirms the match is right
- Sends anything commercial
- Decides actual priority
- Handles anything ambiguous
Always keep the original
Whatever you create — a ticket, a lead, a note — keep the customer’s actual words on it.
Two reasons:
Extraction can be wrong. Whoever picks it up needs to see what was really said.
It is evidence. When a quotation comes out wrong, the original message is how you find out where.
Log the whole chain
What makes an AI step debuggable rather than a black box.
Log three things:
The message as received.
What the model extracted.
What it matched to.
Without all three, a wrong outcome is unexplainable. With them, you can see exactly where it went wrong — was the extraction bad, or was the match?
The confirmation reply
Always send one, and make it do work.
What it should say:
What you understood them to want. This is the important part — it gives them a chance to correct a misreading immediately, before anything goes further.
What happens next.
Because they messaged you, a service window is open — you can reply freely without an approved template.
FIGURE 3: WHAT KEEPS THIS SAFE
Fail visibly on ambiguity
- Never guess at a product or a customer.
Keep the original message
- Extraction can be wrong. Somebody needs the real words.
Log message, extraction and match
- Otherwise a wrong outcome is unexplainable.
Confirm what you understood
- It lets them correct a misreading straight away.
Where the data goes
If you use an external model, the message goes to that provider.
Customer names, order details, whatever is in the message.
Three questions, answered in writing before you send anything:
Is our data retained, and for how long?
Is it used to train their models?
Does this meet our obligations for personal data?
Business tiers usually say no to training. Free tiers often say yes. Know which you are on.
What it is worth
The saving is the assembly, not the decision.
Reading the message, working out what was meant, searching for the products, drafting the reply — that is most of the time and all of the tedium.
Checking and sending takes under a minute.
So the realistic outcome is not “no people involved”. It is work arriving ready to review instead of taking ten minutes to build.
For a business handling many enquiries, that is a real change in capacity.
The short version
A model is justified here because the input is free text, which no rule handles.
Extraction is not matching. Always search your real systems, and fail visibly rather than guessing.
Keep the original message. Log the whole chain. Keep a person on anything commercial.
And confirm what you understood — it is the cheapest way to catch a misreading before it costs anything.
Customer messages being read and retyped into your systems?
Get in touch. We build message-to-system workflows that extract, match against real records, and leave the decisions with your team.
