Before a CRM Agent Acts, Check Which Customer It Has Found
Before a CRM agent changes an order, it needs a defensible customer match and permission for that action. Consider an illustrative address-change request. The agent finds a support ticket, a billing profile, and two order records. The name and email look alike, so it joins them and makes the change. One order, however, belongs to another person who shares the household email. The agent has acted quickly, but on the wrong customer's record.
A fluent model can explain the request and still inherit a faulty view of the customer. The question comes earlier: Which records describe the same person or account, which facts should the agent trust, and which of them may it use for this task?
The match needs a reason
A CRM often holds several versions of one customer. Sales, service, billing, and commerce systems collect different fields at different times. Matching on one shared detail is tempting, but an email address might be reused, a name might change, and a household might share a phone. The safer approach is to make the link between records explicit, with evidence for why it exists and a way to contest it.
The cost of a wrong link depends on the action. A missed match might delay service; a false merge might expose another person's records. Those errors need separate measures, not one accuracy score. An agent might be able to suggest that two records could belong together while it drafts a reply. It should not silently merge them before changing account access or issuing a refund. Where the link remains uncertain, the right answer is a short question or a human review, not a more confident sentence.
An old fact is not a current instruction
Even a correct identity link can carry stale or misleading facts. A delivery address from last year might be true as history but false as a current instruction. A disputed charge might still appear in a ledger, though the customer won the dispute. The U.K. Information Commissioner's Office makes a useful distinction: Organizations should be clear about the source and status of personal data, and an old fact need not be wrong if it is clearly marked as historical.
For a CRM agent, that suggests a practical rule: Return each relevant fact with its source, time and status. Show whether an address came from a recent confirmed order, a free-text note, or an imported list. Keep a correction or dispute attached to the record it changes. If two sources disagree, surface the conflict. Do not flatten them into one apparently settled customer profile.
A customer match and a login prove different things. Matching links records; authentication checks the person making the request. A family member might know an order number without having authority to change the account. NIST's AI risk guidance asks organizations to document how an AI system relies on upstream sources, including content provenance. In a CRM workflow, the same discipline makes an answer traceable: an operator can see which record the agent used, which link joined it to the customer, and which version was current when the action happened.
A record is not permission
A resolved, current record is not a grant of permission. Uncertain matches should restrict retrieval as well as writes: even drafting a reply can disclose private facts. The agent might need an address to answer a delivery question without needing access to payment details or authority to alter them. Retrieval should return the minimum data for the stated purpose, while the system that executes an action checks the user's rights again. The model should not decide its own scope from a persuasive prompt.
The Open Worldwide Application Security Project (formerly the Open Web Application Security Project) has issued guidance on excessive agency that makes the division clear: Keep tool functions narrow, enforce authorization in downstream systems, and require a person to approve high-impact actions. This is not an argument for a human to click through every routine reply. It is an argument for a deliberate boundary. Let the agent explain a status or draft a response; require a stronger identity check and approval before it changes an account, moves money or discloses sensitive details.
The service team must see the check
These controls only help if the service team can use them under pressure. Show the operator the matched records, the reason for the link, and any unresolved conflict. Expose the age and source of a fact. Mark the exact action it proposes, the permissions it has, and the condition that would route it to a person. Log the decision so that a later complaint can be traced to the data and rule in force at the time.
Test the workflow with awkward, ordinary cases before wider release: two people on one email address, an old surname, a recent correction, a disputed transaction, and a support request that crosses account boundaries. Measure wrong joins and wrongful actions separately from answer quality. A polished reply is not a successful service outcome if it drew on the wrong customer or changed the wrong record.
One last check belongs at execution. The customer record or the user's rights might change after retrieval. Revalidate the subject, record version, and permission before committing the change, and log the result. A well-written answer cannot compensate for an action taken against yesterday’s account state.
Steven Renwick is CEO and co-founder of Tilores.io, which builds real-time entity resolution software that runs fully managed on AWS or inside a customer's own cloud. He holds a Ph.D. from UCLA and an MBA from Oxford, and previously founded the fintech company Satago, now part of TruFin.