A retail CRM should connect a purchase to the right customer record without making identity or contact permission an assumption. Define how shoppers are recognised, which purchase information staff need and how contact instructions are recorded. Test anonymous shopping, repeat visits and corrections before combining customer histories or enabling a follow-up workflow.
The challenge is continuity at the till and afterwards. A returning shopper may use a different contact detail, share a household telephone or present a loyalty card without a named customer record. The system needs a deliberate way to resolve those cases while preserving the meaning of each record.
This guide’s original repeat-visit worksheet separates customer identity, attributes, loyalty activity and contact decisions. Microsoft Dynamics 365 Commerce documentation supplies concrete examples of customer fields and loyalty structures; the worksheet helps a retailer examine how those features fit the intended journey.
How should staff identify the returning customer?
Write the intended identity process before choosing fields. Decide which identifier staff search, how they confirm a match and what they do when several records look plausible. A shared telephone number should trigger a careful choice rather than automatically combining everyone who uses it.
Commerce loyalty cards can be issued anonymously or assigned to a customer. This loyalty distinction matters during a return visit. A card can represent participation without necessarily being a named customer identity. Ask the demonstrator to show the relationship among the card, transaction and customer rather than treating them as interchangeable.
Commerce can link a customer record to a loyalty card and pool points from multiple cards. Inspect the intended links using fictional records. Record who may associate a card with a customer and how an incorrect link is corrected. The ability to pool points makes a careful identity decision useful; it does not remove the need to establish that the records belong together.
Keep a clear route for someone who does not want to create a named customer profile. Define the proposed transaction journey and explain which features require identification. Avoid presenting every field on an optional customer form as a condition of receiving ordinary service unless that condition has actually been authorised.
Which customer fields are useful at the till?
Dynamics 365 Commerce can add fields to the customer master through configuration. Configured customer attributes appear on POS customer screens and in headquarters. The customer-attributes guide describes this configuration route. Select fields from a specific service task: a preferred receipt option or a customer category may have a clear purpose, while an unexplained free-text profile field can invite inconsistent entry.
The documented first version does not support datetime or reference attribute types. Preserve the documented scope when planning a field. If a requirement needs a type outside the described support, identify it as a design question rather than assuming the attribute feature covers it. Record the actual version and configuration demonstrated.
A fixed list is available only for the Text attribute type. A controlled list can help represent an agreed set of answers, but the list itself needs an owner. Include a useful unknown or not-recorded state where appropriate instead of forcing staff to choose an inaccurate value just to save the customer.
Dynamics 365 Commerce customer attributes are legal-entity-specific. Check the company context in a multi-entity evaluation. A field configured in one context should not be assumed to appear in another without a demonstration. Retain the entity, screen and selected customer with the evidence so a missing attribute can be investigated precisely.
| Record | What it should mean in the brief | Review question |
|---|---|---|
| Customer identity | The person or organisation recognised for this task | How is a plausible match confirmed? |
| Customer attribute | An agreed characteristic with a clear purpose | Who owns its meaning and correction? |
| Purchase reference | The specific transaction being discussed | Can staff trace the relevant purchase? |
| Loyalty card | Participation and recorded rewards | Is it anonymous or linked to an identified customer? |
| Contact instruction | Channel and purpose decision supplied by the business | What evidence permits the proposed follow-up? |
What does loyalty history tell the reviewer?
Commerce lets users view loyalty transactions and accumulated points for a specific card. Use that view to examine the specific reward activity. Keep the purchase reference available in the proposed service journey so staff can explain which transaction the discussion concerns. A useful history needs enough context for the task, not merely a longer list of points.
Commerce distinguishes redeemable reward points from non-redeemable points used for tracking or tier progression. Commerce loyalty tiers are optional. Define the proposed programme before interpreting its status labels. A non-redeemable tracking balance and a redeemable reward answer different questions. Equally, the absence of tiers is a valid design choice rather than evidence that a programme is incomplete.
Test an ordinary return or correction using the selected product’s documented workflow in a test copy. Record the original transaction, affected reward activity and resulting view. Do not accept an unexplained balance change merely because the new total looks plausible.
How should contact permission be kept distinct?
Create a separate brief for the proposed message: its purpose, intended channel and current instruction. A loyalty relationship, customer category or recorded purchase should not silently stand in for that decision. Ask the retailer’s responsible policy owner to provide the rules and evidence required for the actual contact process.
Record how a changed instruction reaches the tool that sends messages. Test a fictional withdrawal or correction and inspect the downstream result. These are proposed acceptance requirements; the attribute and loyalty documentation cited here does not establish a complete consent workflow by itself.
Keep collection prompts understandable. Explain why a field is requested and distinguish optional information from what the task requires. Give staff a correction route for mistakes so the easiest response is not to create another customer record and leave the original history unresolved.
Original repeat-visit retail worksheet
Use a hypothetical shopper with an anonymous loyalty card, then a separate fictional named profile. Add another person who shares the profile’s household telephone. The deliberately ambiguous fixture lets the reviewer examine the identity decisions before any real records are linked.
First visit: Complete the agreed anonymous journey in the test copy. Record the transaction reference, card relationship and available service history. Write what the staff member can responsibly infer from those records and what still requires identification.
Return visit: Present the card alongside the fictional name. Ask the demonstrator to locate the proposed customer record and explain the evidence for linking them. Introduce the shared telephone match and confirm that the choice remains deliberate rather than automatically merging the two people.
Attribute check: Configure a task-specific test field with an agreed list of values. Inspect it in the intended POS and headquarters context. Record its label, help text, default and owner. Try an unknown answer to ensure the workflow does not force an invented value.
History check: Follow a transaction reference to the relevant loyalty activity. Ask a reviewer to explain the relationship among the transaction, card and customer without relying on the demonstrator’s memory. Preserve any unclear link as a requirement to resolve.
Contact check: Add a fictional purpose-specific instruction, then change it. Inspect the proposed follow-up selection and record who resolves discrepancies. Accept the journey only when identity, history and the contact decision remain separately explainable.
For wider retail systems scope, see business systems and online stores. To discuss the workflow, get started with the repeat-visit worksheet and a fictional example of the customer matches your team needs to handle safely.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.