At 9:30 a.m. on a weekday (sometime last year), I watched an SDR try to write one line of “personalized” outreach with five tabs open: company site, LinkedIn, job board, ad library, CRM. Thirteen minutes later, he had a sentence that sounded like a horoscope.

I’ve done the same. You try to stitch context from scraps. The email looks smart in draft. On the buyer’s side, it reads like guesswork or just disjointed thoughts.

Half-baked lines

If your data lives across five tools, your personalization will always sound half-baked. You and your AI are cooking with missing ingredients. A title without the team behind it. A funding note without the hiring plan. Ad spend without who actually runs demand. The result is that faint “off” smell—close, not quite right.

It also slows you down. Reps spend time gathering, not selling. Context shifts from email to call to demo because each channel pulls a different fragment. Credibility leaks in small ways: a wrong tool mention, an old job title, a pitch that ignores yesterday’s hiring post.

The pivot

The day this changed for me was boring. No big tool. No fancy LLM trick. We built a central repository—a single place that combined what we already had: website signals, job posts and hiring trends, tech stack and ad activity, and the public stuff buyers leave behind on LinkedIn (promotions, new hires, engagement).

Not a data lake. A table. One row per account. Fields we actually use. Updated often enough to trust. AI pulls from it. Humans pull from it. Everyone talks to the buyer from the same page.

One table only

We started small on purpose. A sheet (yes, we went manual first) with columns we knew we’d touch before any email or call: company size, industry, core products, known tools, fresh job posts, open roles in sales/marketing/security, ad library notes, last major announcement, recent LinkedIn moves. Nothing fancy. If a field didn’t drive a line in an email or a decision in a score, it didn’t get a column.

For updates, we took what the web already gives. Job posts and press: daily. Ad library and site changes: every few days. LinkedIn bits: when something notable pops—new VP Sales, a string of team hires, a founder post that blew up. Enrichment APIs filled the dull parts. A simple script handled “last_updated.” If a row went stale beyond its SLA, it got a flag. (Stale context is worse than no context.)

Scenes, not theory

At a fintech in Bengaluru, we kept guessing about “cost pressure.” Turns out they had been hiring RevOps quietly for three weeks. The repository caught it the day the third role went live. The line changed from a generic ROI nudge to: “Saw you’re adding RevOps—are they planning to own lead routing or will SDRs keep that?” The reply came the same day: “Routing is the headache. Show me how you’d set it up.” Meeting booked.

Another one: a mid-market SaaS in Gurgaon had no visible hiring, but their ad spend spiked and the website quietly added a “Partners” page. Our first touch referenced the partner motion and the sudden paid push, not the old “noticed your Series B” line everyone else was using. We didn’t sound smart. We sounded present.

The boring bits

Governance is the unsexy part that makes the sexy part work. We wrote down update frequency per field. We set owners: ops owns schemas, marketing owns site/ad notes, SDR enablement owns job posts and titles, data team owns enrichment. Versioning lived inside the tool (a basic “change log” sheet does the job). Naming rules saved us from the “Acme, Acme Inc., ACME-HQ” mess.

We also decided what not to store. No piles of free text. No “maybe useful later” columns. If a field didn’t help scoring, triggers, outreach, or a handoff to the AE, it was out. You can always add later; you rarely delete fast enough.

Complications happen

We hit the usual last-mile curses. Duplicate domains. People data from two sources fighting each other. A “hiring” signal that was actually a recruiter repost. An SDR adding custom notes in random places. We solved most of it with two rules: the repository is the source of truth, and changes happen through it, not around it. Yes, that means saying “no” to side spreadsheets. Yes, you will be unpopular for a week.

The other wrinkle was speed. Real-time sounds great until you realise real-time means real-time mistakes. We chose “right enough, fast enough” over perfect. Daily for jobs. Every 48–72 hours for ads and site. Instant for manual high-value flags (like “new CISO joined today”).

What changed

Numbers are not everything, but they keep you honest. After four weeks on the central repo:

• Research time before first touch dropped from ~12 minutes per account to ~3.

• First-touch speed moved from “tomorrow” to “same day” on hot accounts.

• Reply rate on cold email lifted from 1.8% to 3.1% across the same ICP.

• “Wrong detail” corrections from prospects (the quiet credibility tax) fell sharply.

The bigger shift was tone. Emails stopped sounding like we skimmed a press release. Calls opened with the right guess. Demos started at the buyer’s map, not ours.

MVP to V3

If you’re early, don’t build a cathedral. Build a spine. One table per account. A handful of fields you actually use. Audit weekly. Add enrichment where it saves human time. When the table starts to groan, move to a simple unified schema in your database. Keep the contract the same: one place, same page, shared truth.

And keep ownership clear. A repository without an owner turns into a museum. Pretty, useless.

Take this with you

You can’t scale personalization if every SDR has to hunt for context. AI can write fluent nonsense when you feed it partial truth. Give both—AI and humans—a single, boring, reliable place to look before they speak. If your data lives together, your message sounds like it came from one brain.

If you want a sample schema (sheet plus basic update rules), say the word. I’m happy to share what we use and why we kept it this simple.

Thanks for reading—subscribe if you want the next chapter on scoring with this spine in place.