What a dirty student lead database actually looks like
A dirty database isn't one big obvious problem β it's dozens of small ones that add up to unreliable targeting. The most common culprit is duplication: the same prospective student fills out a course guide form, RSVPs to an open day, and asks your chatbot a question, and your CRM creates three separate records instead of recognising one person across three touchpoints. Each duplicate then gets its own email and its own line in your reporting, so your "1,200 leads" figure might really represent 850 people.
Invalid contact details are the second layer. Phone numbers get mistyped at entry ("04XX" truncated to nine digits, a landline entered where a mobile was expected), or filled in with a placeholder like "0000000000" just to get past a required field. Emails follow the same pattern: a parent's inbox used once and never checked again, a school-issued address that expires the moment a student finishes Year 12, or a role-based address like admissions@ typed in out of habit. Layer incomplete records on top β no course preference, no consent flag, no source field β and a database that looks large on a dashboard performs far smaller in practice.
Why cleaning before a campaign beats cleaning after
Cleaning after the send fixes your reporting; cleaning before the send protects the campaign itself. Four things go wrong when you launch into a dirty list, none of them reversible once the send button is clicked.
Deliverability takes the first hit. Every hard bounce and spam complaint an inbox provider logs against your sending domain damages the reputation that governs whether your next email β including one to a genuinely interested prospect β lands in an inbox or a junk folder; HubSpot's research on email marketing consistently flags list hygiene as one of the strongest levers on inbox placement, well ahead of subject-line tweaks. Ad spend takes the second hit: uploading a CRM list to build a lookalike audience on Meta or Google Ads means duplicate and invalid records dilute the seed audience and feed the bidding algorithm a distorted signal β Search Engine Journal's coverage of lead quality in paid campaigns makes the same point about backend CRM data shaping ad performance. Admissions staff absorb the third cost, spending hours calling numbers that ring out or records a colleague already actioned. Campaign analytics take the fourth hit β a channel that converts well can look weak simply because its contacts were duplicated into a different source bucket, undermining the attribution work in our guide to calculating the true cost per enrolment by channel.
Deduplication logic that actually catches the right duplicates
Effective deduplication runs on rules, not gut feel β you need a defined matching logic before you can safely merge or delete anything. Two signals catch most real duplicates: a normalised email address (lowercase, stripped of dots and plus-aliases where your provider allows it) combined with a fuzzy match on full name, and a normalised phone number compared on the last nine digits so "0412 345 678," "+61 412 345 678" and "412345678" register as the same contact. Matching on name alone is too loose β it collides siblings and common names β while matching on email alone misses the prospect who used a different address for the open day form than the chatbot conversation.
The harder decision is which record survives a merge and which fields it keeps. A blanket "keep the newest record" rule sounds simple but often discards a more complete older record in favour of a thin new one.
| Field | Survivorship rule |
|---|---|
| Contact details (phone, email) | Most recently verified, not most recently entered β a bounced address from last week loses to a validated one from three months ago |
| Course/program interest | Most recent value wins β interests genuinely change over an admissions cycle |
| Source/channel | First-touch value wins β this protects attribution and CAC reporting |
| Consent/opt-in status | Most restrictive value wins β if either record opted out, the merged record stays opted out |
| Notes and interaction history | Combine, don't overwrite β admissions staff need the full conversation trail |
Records with no valid contact method at all, no source, and no interaction in over 12 months are candidates for deletion rather than merging β there's nothing left to reconcile.
Phone and email validation: format checking versus real verification
Format validation and real verification solve different problems, and conflating them is the most common mistake mid-size admissions teams make. Format validation checks that a phone number matches the Australian numbering pattern β a 10-digit mobile starting with 04, or a valid landline with area code β and that an email follows standard syntax with an "@" and a resolvable domain. It's fast, free to automate, and should run the moment a record is created, not weeks later during a pre-campaign audit.
Real verification goes further: does that email actually accept mail, does that phone number connect to an active line. This is worth automating in bulk through a verification API run quarterly, or immediately before a major campaign β a bounce-and-blocklist incident costs more than the verification run itself. What's not worth automating for a mid-size team is the judgement call on ambiguous records: a landline where a mobile was expected, a parent's number tagged to a prospect's profile, or a number valid in format but attached to a prospect gone silent for two admissions cycles. Route those to a short manual review queue instead of engineering rules to guess intent β a human glance at 40-50 ambiguous records a week beats the automation effort needed to replace that judgement.
The pre-campaign database checklist
Run this checklist against your full list at least a week before any campaign send, not the day of β cleaning takes longer than it looks once you find genuine problems. Google Search Central makes the same case for content: trustworthy, accurate signals beat volume, and the same holds for a contact list feeding a campaign.
| Check | What to look for | Action |
|---|---|---|
| Duplicate contacts | Same normalised email or phone across >1 record | Merge using survivorship rules, don't delete blindly |
| Invalid phone format | Wrong digit count, placeholder numbers ("0000000000") | Flag for manual review or remove from SMS/call lists |
| Unverified email | Syntax valid but not confirmed to accept mail | Run through a bulk verification tool before sending |
| Role-based or expired addresses | admissions@, info@, expired school-issued domains | Suppress from personal nurture sequences |
| Hard bounces from prior sends | Any address that bounced in the last 2 campaigns | Suppress permanently, don't re-attempt |
| Missing consent flag | No record of opt-in source or date | Exclude from the send until consent is confirmed |
| Stale records (>12 months, no interaction) | No open, click, call, or chatbot session in a year | Move to a reactivation sequence or purge per your retention policy |
| Incomplete profile | No course preference or intake year recorded | Deprioritise for segmented sends; fine for a general nurture |
Purge or suppress: what the Privacy Act says about stale records
You can't hold a stale prospect's data indefinitely just in case a future campaign might use it β Australian privacy law is specific on this point. Under the Privacy Act 1988 and Australian Privacy Principle 11, an organisation must take reasonable steps to destroy or de-identify personal information once it's no longer needed for the purpose it was collected for, and the OAIC's guidance on the Australian Privacy Principles treats an indefinite "just in case" hold as a compliance gap, not a neutral default. A prospect who never responded to a reactivation sequence β see our piece on reactivating a dormant student lead database β should move to a documented deletion step, not sit untouched for another two admissions cycles.
In practice this means setting a retention window β commonly 18-24 months of total inactivity for prospects who never enrolled β and applying it consistently, not deciding case by case whenever someone notices an old record. TEQSA-registered providers also carry the expectation that marketing communications stay accurate and current, so a stale record still triggering emails about a discontinued course or last year's ATAR cut-off compounds the privacy problem with a credibility one.
Structured intake: how a chatbot stops dirty data at the source
The cheapest way to clean a database is to stop dirty records entering it in the first place, and this is where lead capture design matters more than any downstream cleanup. A generic web form accepts whatever a visitor types β a chatbot conversation can validate a phone number's format and an email's syntax at the exact moment the prospect provides it, prompting a correction before the record is ever created rather than flagging it in a batch review months later.
That point-of-entry validation compounds across a full recruitment funnel. Schools using an AI chatbot see qualified leads per month rise from 120 to 195 β a 62% increase β while cost per lead falls by 38% (source: Skolbot partner panel, 18 European schools, 2024-2025, median results). That's a European benchmark cited here for comparative context, not an Australian-specific figure, and the improvement combines the chatbot's own effect with the funnel optimisations schools typically run alongside it β no single channel explains the full gain on its own. What's directly relevant to database quality is the mechanism: a conversational intake that rejects "0000000000" or confirms an email domain before saving means your admissions team spends its time on prospects who actually exist, not cleaning up after the fact. That complements rather than replaces admissions counsellors, freeing them up for genuine conversations instead of chasing unreachable numbers.
Choosing the right intake and CRM combination matters here too β our comparison of CRM platforms built for higher education covers which systems support this kind of validation natively, and our broader digital marketing guide for Australian higher education sets out where clean intake fits alongside your other acquisition channels.
FAQ
How often should we clean our student lead database?
Run the full checklist at least a week before every major campaign send, and schedule a lighter monthly pass for bounce removal and duplicate merges. Starting the cleanup once a campaign is already scheduled almost always means skipping steps under time pressure.
What's the fastest way to find duplicate contacts in our CRM?
Export your contact list and sort by normalised email and phone number (stripped of formatting and country codes) rather than by name β name-based sorting misses far more duplicates than it catches, and most CRM platforms support this matching through a built-in deduplication tool or a simple spreadsheet formula.
Should we delete invalid records or just suppress them from campaigns?
Suppress first, delete later. Moving an unreachable or bounced contact to a suppression list protects deliverability immediately without destroying interaction history you might need for reporting, and it gives you a documented step before the eventual deletion required under APP 11.
Does format validation alone stop fake phone numbers?
No β format validation only confirms the number has the right shape, not that it's a real, reachable line. Catching placeholders like "0000000000" needs a real verification pass, ideally run in bulk before a campaign or, better, at the point of entry through a chatbot that rejects obvious placeholders on submission.
Will cleaning our database reduce our total lead count?
Yes, and that's the point. A database that drops from 1,200 records to 850 after deduplication and validation hasn't lost 350 prospects β it's revealed those 350 were never separate, reachable people. Campaign performance measured against the smaller, accurate number looks better, not worse, because open, click and reply rates stop being diluted by contacts who could never have responded.
Try Skolbot on your school in 30 seconds


