Why does the same customer exist several times in our application?

Because they come in through several doors, till, WhatsApp, online shop, app, field sales, and no rule says it is the same person: the name is written differently, the phone too, and every door creates its record without searching first. The fix is an architecture, not typing discipline: the normalised phone as key, a search before any creation, and a resolution that matches the raw records.

What happens if two people share the same number?

A number may carry several people, the shop’s or the family’s phone for instance. Automatic merge is refused if names differ, and each person keeps their record, attached to the same number. That is why an identical phone alone is not enough to merge: the rule also checks the name, and when in doubt, suggests instead of deciding.

Can a merge be cancelled?

Yes, in one gesture, because the two source records are never modified: the merged record points to them, and unmerging removes the link. Every merge is logged with who, when, the score and the rule. That reversibility is what allows automatic merge above a threshold; without it, no merge could be delegated to a rule.

How long to make a customer file single?

Six weeks: one to write the doors, the key, the thresholds and the survivorship rules, one for normalisation and measuring the old file, one for matching and the score, one for the single record and the merge, one for the uses, one to install the morning review. The first week has no code, and it is what avoids the merges you regret.

One customer, not three: building a single customer file in your application in Algeria in 2027, from the till to WhatsApp, the phone as key, merging and history

Short answer. A customer comes in through five doors, till, WhatsApp, online shop, app, field sales, and every door keeps its dated raw record. The phone, normalised to international format at entry, is the key looked up first, because it compares, where a name in Arabic and French does not. Matching looks for the exact first, then the approximate, name and wilaya, and gives a score; above a written threshold the merge is automatic, between two thresholds it is a suggestion a human reviews in the morning, below it is two records. The single record is computed from the sources, never typed, with a survivorship rule per field: the verified phone wins, the most complete name keeps the other script, points add up, consents take the most restrictive. Every merge is logged and undone in one gesture, because the sources are never modified. Six weeks, the first without code.

This guide is for the manager of a shop chain who no longer knows how many customers they have, the founder settled in France whose online shop and Algiers till talk poorly to each other, and the person who must reconcile a loyalty programme with duplicate records. It does not repeat how an old file is deduplicated at migration time, described in the data migration guide, nor how points are computed, described in the loyalty guide; it describes what is built so that a customer stays unique day to day, door after door, and extends our page on software engineering.

What the references say

The phone is the only key that normalises, and its form is public. The Algerian numbering plan gives the country the code +213 and the trunk prefix 0; a mobile number has “nine digits” after that 0, in the form “0yxx xx xx xx” where “y is the operator code, 5 for Ooredoo, 6 for Mobilis, 7 for Djezzy”; a landline has eight, with an area code, 021 or 023 for Algiers, 036 for Sétif. The international numbering standard limits a full number to fifteen digits. What this imposes: “0661 23 45 67”, “+213661234567” and “00213 661 23 45 67” are the same number, and a normalisation function that knows these rules brings them all to +213661234567 before any search; a number that does not normalise is refused at entry, not stored as is.

The name, for its part, does not normalise, which is why it is not the key. An Algerian customer is “Benali Karim” at the till when the employee types in Latin, “بن علي كريم” when they type in Arabic, “Karim B.” on WhatsApp, and the transliteration of one Arabic name into Latin letters admits several forms; no engine sees them as equal without rules, and rules get it wrong. What this imposes: the name is stored in both scripts, per the bilingual application guide, it serves to confirm a match proposed by the phone or e-mail, and it never merges automatically on its own.

What we did not find: a public measure of the duplicate rate in Algerian companies’ customer files. What we see on the files we take over is between one record in ten and one in six duplicated when several doors have existed for over a year without a common rule, and we say so as an observation, not a statistic. A file without duplicates does not exist; a file whose duplicate rate is measured every month and reviewed every morning does.

One customer, five doors, one single record

The single customer file is not understood on a database schema but on a real customer who comes in through five doors over eight months.

Figure 1 · Five doors, five ways of writing the same number and the same name, and one record at the end. The resolution box normalises first, matches next, scores the confidence, and decides: automatic merge when the normalised phone is identical, a suggestion to review when only name and wilaya agree. Every door keeps its raw record and its date; the single record is computed, never typed. The data is an example.

In March, Karim buys at the counter; Amel types his name in Arabic and his number, 0661 23 45 67. In May, he writes on WhatsApp from +213661234567 and accepts promotions; first name and an initial. In September, he orders on the online shop with his e-mail and a number written 00213 661 23 45 67. In October, he installs the app and verifies his number with a code, per the phone login guide. In November, the field rep visits his mini-market and records him as “Supérette El Hidhab, Karim”, with the same number written yet another way. Five raw records, five dates, five ways of writing the same person.

Resolution does four things, in order: it normalises the phone, the name and the e-mail; it matches, first on the exact phone, then on name and wilaya; it scores the confidence; and it decides, automatic merge when the normalised phone is identical, suggestion when only name and wilaya agree, nothing below. The single record that comes out carries the phone verified by the app’s code, the name in both scripts, the shop’s e-mail, the rep’s wilaya and outlet, and the consents given on WhatsApp; and every field says where it comes from. The data is an example; the rule is not: the single record is computed, never typed.

«The single record is computed from the sources, never typed; you correct a source, and the record recomputes.»

Six real situations, and what the application does

Six situations that recur on almost every customer file, and what the application does for each.

Figure 2 · The first two rows are settled by normalisation and matching; the next two say why automatic merge is never total: a shared number and a name in two scripts need a human or a code. The last two come after the record: the company with several buyers and the deletion that must not erase invoices.

The same number, three spellings: normalisation to international format at entry makes them find each other; it is the most frequent and simplest situation. Two numbers, one person: the customer changed operator; the match by name and wilaya is suggested to the employee and confirmed by a code on the new number; the old one stays in history. One number, several people: the shop’s or the family’s phone is given by three buyers; a number may carry several people, automatic merge is refused if names differ, and that is why the phone alone does not merge without checking the name.

The name in Arabic and French: both scripts are stored and searched, per the search guide, but matching goes through the phone, and the name only confirms. The B2B customer with several buyers: a company record and attached person records, loyalty and credit on the company, consents on the people; it is the structure of the B2B portal. The customer asking for deletion: the record and its sources are anonymised, invoices kept with the customer number only, the operation logged and irreversible; it is the case where keeping sources does not mean keeping them nominative.

One merge, field by field, and its undo

The merge is the operation people fear most, which is why it is the most constrained.

Figure 3 · A merge overwrites nothing: every field has a rule, the verified phone wins, the most complete name keeps the other script, points add up, consents take the most restrictive per channel; the merged record points to its two sources, kept as they were, and the log line says who, when and with which score. That is what makes unmerging possible in one gesture, and what we require before allowing automatic merge.

Two records: A, created at the till in March with fourteen purchases; B, created on the shop in September with three orders; the normalised phone is identical, the score is 0.96, the merge is suggested and Amel confirms it from the till. One rule per field: the phone verified by code wins; the most complete name wins and the other script is kept; the present e-mail wins; the most recent address wins and the other is kept; loyalty points add up; consents take the most restrictive per channel, because a customer who refused SMS on one record refused them, full stop.

Nothing is overwritten: the merged record points to its two sources, kept as they were with their history, and the log line says who merged, when, with which score and by which rule, per the audit log guide. Unmerging happens in one gesture, because the sources were never modified: you remove the link, and both records resume their lives. That reversibility is what allows automatic merge above the threshold; without it, every merge would be an irreversible decision no manager would delegate to a rule.

«A merge overwrites nothing: the sources are kept, the log says who and why, and unmerging happens in one gesture.»

A single customer file, in five layers

Behind those merges, five layers, and the one that decides how many customers you have.

Figure 4 · The accented layer decides how many customers you have: with a single threshold and always-automatic merge, you merge different people sharing a phone; with no threshold, you keep three records per customer. Two written thresholds and a queue of suggestions reviewed in the morning are what holds between the two.

Entry doors: till, WhatsApp, shop, app, field sales, import of an old file; each produces a dated and signed raw record, and nothing is written directly into the single record. Normalisation: phone in international format, name in both scripts, lowercase e-mail, wilaya from a list, structured address; done at entry and redone at every import, and the rule lives in the code, not in an employee’s head. Matching: exact key first, approximate next, a score and three decisions; with a single threshold and always-automatic merge, you merge different people who share a phone; with no threshold, you keep three records per customer; two written thresholds and a suggestion queue reviewed in the morning hold between the two.

The single record: computed from kept sources with a survivorship rule per field; merge and unmerge logged; a company record for B2B; you correct a source, and the record recomputes. Uses: loyalty and credit on the right record, messages sent once with the right channel’s consent per the notifications guide, full history at the till and in the WhatsApp agent, segments for campaigns; the reason for everything else, a customer who receives the promo once and whose seller sees everything.

When a customer shows up at a door

The file stays single because every door makes the same six gestures, in the same order.

Figure 5 · The first step changes everything: ask for the phone before the name, because the phone normalises and compares, and the name does not compare from one script to the other. The third searches before creating, and the fifth creates only as a last resort; it is the opposite of what applications with three records per customer do.

Ask for the phone first, because it is the only field that identifies; the name comes after, and only confirms. Normalise to international format before any search. Search, exact on the phone, then approximate on name and wilaya; it is the step applications with three records per customer skip, because they create first and never search. Propose the record found, confirmed by the employee who sees the name and the last purchase, or by a code sent to the phone when the customer shows up themselves, on the shop or the app.

Create only if nothing: a dated raw record, signed by the door and the employee, which will enter resolution like the others. Log the source: who, when, through which door; the single record recomputes. The till makes these six gestures in three seconds and without network, per the point-of-sale guide; the shop makes them at account creation; the field rep makes them on their tablet in the round application, and resolution catches up when network returns with what could not be matched on site.

Seen elsewhere: the numbering plan and the practice of large files, and what transposes

Two sources say the essentials. The Algerian numbering plan says the exact form of a number, nine mobile digits after the 0, eight landline digits with an area code, and the international standard says its maximum length; what transposes is a normalisation written in the code that brings every spelling to one and refuses what does not fit. The practice of large customer files, at operators and banks, always separates source records from a computed reference record, with survivorship rules per field and a log; what transposes is that the record is never typed, and the merge can be undone.

What these sources do not say: your thresholds, your survivorship rules, and who reviews suggestions in the morning; the project’s first week answers that, and the manager signs the list of doors and rules.

The rules of a customer file that stays single

Six rules, written in week one. The normalised phone is the key, looked up before creating. Every door keeps its dated raw record; nothing is written directly into the single record. Two thresholds: automatic merge above, suggestion between, nothing below. One survivorship rule per field, written, and consents take the most restrictive. Every merge is logged and reversible, because sources are never modified. The suggestion queue is reviewed every morning, and the duplicate rate measured every month.

A seventh rule concerns the quote: “customer management and deduplication” is not a requirement, it is a sentence; the requirement reads “list of entry doors with dated and signed raw record; normalisation of phone to international format, name in both scripts and e-mail at entry and import; exact then approximate matching with score and two written thresholds; computed single record with survivorship rules per field; logged merge and unmerge, kept sources; company record for B2B; consents per channel; anonymisation on request with kept invoices; suggestion queue and monthly duplicate rate in supervision”, and it is checked as the specification guide recommends. A quote that writes “duplicate detection” without saying what happens when one is found has planned an alert, not a single record.

Six companies, and the door that created duplicates

Six companies we often equip, and for each the door that created the most duplicates and what fixed it.

The shop chain, described in the point-of-sale guide. Every till created its record; the phone asked first and normalised brought three records per loyal customer down to one.
The loyalty programme, described in the dedicated guide. Points were scattered across duplicate records; adding them at merge gave them back to the customer, and the complaint at the counter stopped.
The wholesaler and its portal, described in the dedicated guide. The manager, his son and the mini-market’s employee each ordered with their phone; the company record attached all three.
The shop run from France, described in the dedicated guide. The online shop and the Algiers till each had their file; the founder now sees one customer, their online and counter history, on their dashboard.
Field sales, described in the dedicated guide. Every round created “Supérette X, Karim” records; search before creation on the tablet, and resolution when network returned, stopped the leak.
The gym, described in the dedicated guide. A member re-registered every year under a new record; the phone verified by code at registration gave back the subscription history.

The 2027 calendar

The calendar is that of a customer file made single in six weeks, the first without code.

Figure 6 · Six weeks, and the first passes without code: you write the list of doors, the key, the thresholds and the survivorship rules, because a merge done with the wrong rules is hard to undo at scale. The morning review starts in week six and never stops: it is what keeps the duplicate rate low.

Week 0 to 1 writes doors and rules: the list of entry doors, the phone as key, normalisation rules, the two thresholds, survivorship rules per field; signed by the manager, because a merge done with the wrong rules is hard to undo at scale. Week 1 to 2 puts normalisation at entry on every door and normalises the old file, whose duplicate rate is measured for the first time. Week 2 to 3 builds matching: exact then approximate, score, automatic merge above the threshold, suggestion queue for the rest.

Week 3 to 4 builds the single record: survivorship rules, kept sources, logged merge and unmerge, company record for B2B. Week 4 to 5 connects the uses: loyalty, consents per channel, history at the till and on WhatsApp, segments, and the first campaigns sent once. Week 5 to 6 installs the morning review, the suggestion queue reviewed by one person, and the duplicate rate measured every month; it never stops. Every batch is demoed as the delivery guide describes, and the takeover of the old file follows the dedicated guide.

What makes a single customer file fail

The files we take over almost always failed for one of these reasons.

The name as key. Two scripts, three transliterations, and no match holds.
Creating before searching. Every door creates its record; nobody searches first.
The phone stored as typed. 0661, +213 and 00213 are three customers.
A single rule: merge. The shop’s phone merges three buyers into one.
The merge that overwrites. Sources are lost; a merge error is irreversible.
Consents that add up. The customer who refused SMS on one record receives them through the other.
Nobody reviews suggestions. The queue grows, then is ignored, then duplicates come back.

Frequently asked questions

The questions we receive from managers, founders and IT managers.

Why does the same customer exist several times in our application?: Because they come in through several doors, till, WhatsApp, online shop, app, field sales, and no rule says it is the same person: the name is written differently, the phone too, and every door creates its record without searching first. The fix is an architecture, not typing discipline: the normalised phone as key, a search before any creation, and a resolution that matches the raw records.
Why the phone and not the name?: Because the phone normalises and compares: the numbering plan says its exact form, and 0661…, +213661… and 00213 661… become the same number. The name does not compare from one script to the other, “بن علي كريم” and “Karim Benali” are equal for no engine without rules that get it wrong. The name confirms a match, never merges on its own.
What happens if two people share the same number?: A number may carry several people, the shop’s or the family’s phone for instance. Automatic merge is refused if names differ, and each person keeps their record, attached to the same number. That is why an identical phone alone is not enough to merge: the rule also checks the name, and when in doubt, suggests instead of deciding.
Can a merge be cancelled?: Yes, in one gesture, because the two source records are never modified: the merged record points to them, and unmerging removes the link. Every merge is logged with who, when, the score and the rule. That reversibility is what allows automatic merge above a threshold; without it, no merge could be delegated to a rule.
What happens to consents and points in a merge?: Every field has its survivorship rule, written in week one: loyalty points add up; consents take the most restrictive per channel, a customer who refused SMS on one record refused them full stop; the phone verified by code wins; the most complete name wins and the other script is kept; the most recent address wins and the other is kept.
How long to make a customer file single?: Six weeks: one to write the doors, the key, the thresholds and the survivorship rules, one for normalisation and measuring the old file, one for matching and the score, one for the single record and the merge, one for the uses, one to install the morning review. The first week has no code, and it is what avoids the merges you regret.