You Already Paid For The Database You're Not Using

Review notes: Problem-aware. Publish this BEFORE the WhatsApp-blocking post — they are deliberately in tension and this one references it. Evidence: travel agency, hospital group, property brokerage, hotel operator.

A travel agency told us they had 75,000 contacts.

Eighteen years of travellers. People who had already trusted them with money, already been somewhere, already come back or not come back. The single most valuable marketing asset a business of that age can own.

We asked what state the data was in.

"I mean, they are in Excel."

And a moment later, from a colleague:

"It's not arranged."

Seventy-five thousand relationships, in a spreadsheet, unarranged. Not lost — worse than lost. Present, paid for, and unusable.

The four flavours of dead database

We've now seen this in four distinct forms, and they need different fixes.

Too messy to import. The travel agency above. The data exists but the columns don't agree, the phone formats vary, duplicates are everywhere. Every migration attempt stalls on cleanup that nobody has time to do.

Locked in the wrong system. A private hospital group's patient records live in their clinical system, which is excellent at being a clinical system and cannot run a campaign. Their marketing lead: "If we require to send email, we have to download from the system manually and use it. Send it manually." The list is right there. Getting it out is a manual export, every single time.

Too thin to act on. A property brokerage's records contain property type and area, and essentially nothing else. The principal, on being shown what a bot could tell him: "So you currently have — it owns in downtown... What can the bot give me, one more piece of information for that person? I already know he's in downtown." He then diagnosed his own problem better than we could: "We cannot have one sequence that fits all. We need to segment those guys, and those segments will decide the strategies for every sequence." You cannot segment on one field.

Complete, and simply never used. The most painful version. A hotel operator: "I have their numbers, I know their names, I knew when they checked in, et cetera. But there is no follow-through after that to touch base with them." Nothing is broken. Nobody ever got round to it.

Why "just import it and start emailing" fails

Because the reason it hasn't happened is never technical capacity. It's that the people who would do it are the people doing everything else.

The travel agency again, on why their setup kept stalling: "Because I told them, can we update this after office? Because we're doing the sales as well." And: "I didn't get time to attend this onboarding, because in the daytime I have clients to deal with."

This is the defining constraint of a service SME. There is no admin layer. The person who would configure the system is the person generating the revenue, and revenue wins every time — correctly.

So any plan that begins "first, clean 75,000 rows" is not a plan. It's a wish.

A sequence that actually gets started

Ordered deliberately so that value arrives before the boring part.

1. Don't clean it. Segment one slice. Pick the 200 most recent customers, not all 75,000. Recent data is cleaner, and recent customers remember you. This is a morning's work, not a quarter's.

2. Send one thing that isn't a promotion. For the hotel, this is a check-in message. For the school, an application-status update. The goal is a reply, because a reply is what turns a dead row into a live conversation and tells you the number still works.

3. Let the replies clean the data. Every response validates a contact. Every bounce or failure marks a dead one. You're now cleaning the database as a by-product of using it, instead of as a prerequisite for using it.

4. Only then go wider. With one slice proven and a working process, the remaining rows are a volume problem rather than a risk.

5. Fix the intake so it stops happening. The reason the database is a mess is that nothing captured contacts properly at the point of contact. The hospital group's flow ran WhatsApp → Google Form → manual re-registration in the clinical system. Three systems, two manual steps, every patient. Until that's closed, you're bailing a boat with a hole in it.

One honest warning

A hospital group told us about the wall they hit when they tried exactly this: "Number of WhatsApp being sent out, they have a limit... more than 200 it will be blocked, right?" A travel agency, independently: "We can't use that number in the ads. One time we tried two different ways, but it got blocked later."

Waking up a dormant database means sending volume to people who haven't heard from you in a long time — which is precisely the pattern that gets WhatsApp numbers restricted. Doing this without understanding the messaging rules is how businesses lose the channel they were trying to activate. That's the next post in this series, and it's worth reading before you start rather than after.

Honest assessment

• If your contacts are older than about three years and you've never messaged them, expect a low response rate and some annoyance. Consent and recency matter, both legally and practically.
• Thin data can't be enriched by software alone. The brokerage's one-field problem needs a change to how information is captured going forward, not a clever tool applied backwards.
• This work has a real ceiling. A dormant database is a one-off windfall plus a modest ongoing lift. It is not a demand-generation strategy.

LinkedIn native post (link in first comment)

A travel agency told me they had 75,000 contacts.

Eighteen years of travellers. People who'd already trusted them with money.

I asked what state the data was in.

"I mean, they are in Excel."

Then his colleague added: "It's not arranged."

Not lost. Worse than lost — present, paid for, unusable.

I've now seen four versions of this:

1. Too messy to import (the 75,000 in Excel)
2. Locked in the wrong system — a hospital group whose patient list sits in a clinical system: "If we require to send email, we have to download from the system manually. Send it manually."
3. Too thin to act on — a property brokerage with property type and area and nothing else: "I already know he's in downtown. What else can you tell me?"
4. Complete, and never used — a hotel owner: "I have their numbers, I know their names, I knew when they checked in. But there is no follow-through."

The fix isn't "clean the database." It's never going to happen, because the person who'd do it is the person selling.

Take 200 rows. Not 75,000. Send one thing that isn't a promotion. Let the replies do the cleaning.

Full sequence + one important warning about getting your WhatsApp number blocked 👇

LinkedIn article angle

Build it around the "there is no admin layer in a service SME" insight — that's the genuinely useful idea and it generalises well beyond databases. Title: There Is No Admin Layer.

CTA

The five-step sequence → website.

Yalla is the chat-native CRM where the AI does the work, not just the talking.

See how much of your business it can reach.