Student Lead Deduplication Across Channels: A UK Admissions Guide

Deduplication means one record per applicant, with the history intact

Student lead deduplication across channels is the practice of recognising that a web enquiry, a chat conversation, a message on a messaging app and a missed call belong to the same person, then attaching them to a single CRM record. The aim is not a tidy database for its own sake. It is that one adviser contacts the applicant, once, with the full context.

Duplicates hurt admissions teams more than most sales teams because the journey is long and emotional. Someone who requests a prospectus in September, asks a question in chat in October and phones back in November is one prospective student. With three records you get three follow-ups, perhaps from three advisers, and a history nobody sees in full.

This guide covers where duplicates come from, which matching keys to use, what merge rules to write down and which data protection safeguards to build in. It extends our piece on cleaning a student lead database and the one on lead routing and SLAs.

Where duplicates are born: a different identifier per channel

Each channel captures a different identifier, and that mismatch manufactures duplicates. The table shows what you typically know about the person at each entry point.

Two cases need an explicit rule. The first is the parent who writes on behalf of a son or daughter: two people, one file. The second is the applicant who uses two email addresses. No tool resolves either alone; they are policy decisions.

Choose matching keys from the safest to the most fragile

Good deduplication applies keys in a fixed order and stops as soon as a match is certain. Three tiers are enough to start.

1. Exact match. The same normalised email (lower case, trimmed) or the same normalised phone number. Matching can be automatic.
2. Probable match. The same first and last name with the same course of interest, or the same phone with different emails. The system suggests; a person confirms.
3. Possible match. Similar names or variable spellings. Flag them, never merge automatically.

For phone numbers, normalise to the international format in ITU recommendation E.164: country code, then number, no spaces and no leading zero. A number stored as 07… in the CRM and +44 7… in a messaging tool is the same number, and without normalisation it becomes two records.

One caution: never merge on name alone. Namesakes exist, and a wrong merge mixes two applicants' files, which is worse than a duplicate.

Write merge rules before the first merge

A merge decides which value survives when two records disagree. Without written rules each adviser decides differently, and the database drifts back within weeks.

A simple rule set to adapt:

• Master record. The oldest record stays and the others attach to it. It keeps the identifier your other tools already know.
• Contact details. The most recent verified value wins; the older one goes to the history rather than being deleted.
• Course and entry route. Keep the latest stated interest and preserve earlier ones. An applicant who changes course is a commercial signal, not an error.
• Owner. The adviser with the most recent human contact keeps the record; otherwise apply your routing rule.
• Consent and objections. See the next section: the most restrictive setting always wins.
• Audit trail. Log who merged what, when and why, so it can be reversed.

Keep un-merging possible. A hasty merge on a phone number shared by siblings must be undoable without loss.

Data protection: a merge must never erase an objection

Merging records is processing personal data, and UK data protection law applies to the resulting database. The Information Commissioner's Office publishes UK data protection guidance for organisations. The accuracy and data minimisation principles are directly relevant: accuracy supports deduplication, while minimisation rules out keeping everything just in case.

The key risk is objections. If any merged record carries a marketing objection or an erasure request, the surviving record must inherit it. Otherwise the merge revives a contact the person had already refused. Have your data protection officer review your rules, including the separate rules on electronic marketing messages.

Three habits reduce risk:

• Store the date and source of each consent, channel by channel: agreement to email does not cover messaging or phone calls.
• Apply the most restrictive setting when two records conflict.
• Keep a suppression list separately, so that a later import cannot recreate someone who opted out.

For applicants under 18, involve a parent or guardian in exchanges that commit to an enrolment decision, and do not merge the parent's record into the applicant's.

Put the process in place in six steps

A university or college can start with the tools it already has. Order matters more than sophistication.

1. List every entry point: forms, chat, messaging, phone lines, fairs and partner lists. Note what identifier each captures.
2. Normalise on entry: lower-case emails, international phone format, cleaned names. Preventing a duplicate costs less than merging one.
3. Turn on CRM detection: most CRMs offer duplicate rules; configure them on your keys, in suggest mode before automatic mode.
4. Clear the existing stock in batches, starting with exact matches.
5. Write the ownership rule: who takes over the merged record and how the other adviser is told.
6. Review monthly the rejected suggestions and reversed merges to tune your keys.

If several institutions or brands share a database, decide first whether an applicant may be matched across them. That is a purpose-of-processing question to settle with your data protection officer before any cross-brand merge.

Measure without inventing a benchmark

No public source says what duplicate rate is normal in a university, so measure your own before and after. These indicators can be computed from the CRM.

Do not present fewer duplicates as more enrolments. Admissions outcomes have many causes, and the effect on conversion has to be established against your own comparison periods.

What Skolbot contributes, and what stays with the institution

Skolbot Chat is an agent installed on the institution's website. It answers from content the institution has published, qualifies the enquiry, offers an appointment or open day and passes the conversation to the team and the CRM. Capturing an email or phone number early in the conversation gives you a matching key that anonymous visitors usually lack. The wider logic is in our article on AI agents from first contact to CRM.

Matching and merge rules remain the institution's and its CRM's. How exactly the connector behaves with your CRM is confirmed during scoping, not in a blog post. To place your tooling, see the CRM comparison for higher education, and for the big picture return to our guide to recruiting more students.