We Scraped Our CRM and Built a $1M Insight in 48 Hours — Here's the Exact Prompt

We Scraped Our CRM and Built a $1M Insight in 48 Hours — Here's the Exact Prompt

From Raw Records to Revenue: How One Prompt Turned Our Messy CRM Into $1.2M in New Business 📊✨

By Dr. Julie Jones, PhD in Artificial Intelligence


We had 47,000 customer records sitting in our CRM for three years. Most were stale. A few thousand were duplicates with slightly different email addresses and inconsistent phone formats. The sales team knew the data was underutilized — they just didn't know how to mine it without a data engineer on retainer and a six-week project timeline.


So we did what any pragmatic product team does: we wrote one prompt, pointed an LLM at a cleaned slice of the CRM, iterated for two days, and shipped a customer-segmentation playbook that our sales reps actually used. The result: 340 qualified leads re-contacted within three weeks, $1.2M in closed-won pipeline attributed directly to those contacts, and a repeatable prompt we now use on every new data dump.


This article is the full breakdown — the exact prompt, the data prep that made it work, the failure modes we hit, and how you can adapt this pattern to your own CRM, ticketing system, or any tabular gold mine you're sitting on.

Why 48 Hours Instead of 6 Weeks

Traditional "CRM analytics" projects follow a familiar arc: stakeholder interviews (1 week), schema mapping and deduplication (2 weeks), ETL build-out (2 weeks), dashboard construction (2 weeks), user training (1 week). Total: eight to ten weeks, $40K+ in billable hours, and a PowerBI or Looker dashboard that 60% of the team opens twice.


The LLM approach collapses most of that into a conversation. The model doesn't replace your data pipeline — it replaces the interpretation layer, which is where most of the time actually goes. You still need clean-ish input. But once you have it, going from "here's our customer table" to "here are the five segments with the highest expansion potential and exactly what to say to each" can happen in a single afternoon.


The 48-hour window we used was not a marketing number. Day one was spent on data hygiene and prompt v1–v3. Day two was spent on validation, edge cases, and turning output into an actionable playbook our reps could read over coffee. We measured the clock from "opened Jupyter notebook" to "reps have their first call scripts in hand."

The Data Prep (The Boring Part That Matters)

You can skip this section if your CRM is already clean. You should not skip it if it isn't. Here's what we did before the prompt ever touched a single record:


Deduplication and normalization. We wrote a 40-line Python script using pandas and fuzzy matching (fuzzywuzzy) to collapse near-duplicate accounts. Threshold of 85% similarity on account name + email domain caught roughly 1,900 duplicates in our 47K-record set. Phone numbers got normalized to E.164 format. Dates went into ISO-8601.


Column curation. CRMs accumulate columns like a garage accumulates junk. We had 83 fields; the prompt only needed 22. The ones that mattered: account_name, industry, employee_count, annual_revenue_band, last_login_date, tickets_open_90d, tickets_closed_90d, csat_avg_12mo, renewal_date, primary_contact_email, department_tags, and a handful of custom fields our team actually used.


Chunking for context. We split the 47K rows into six chunks of roughly 8,000 records each. Each chunk had ~2MB of JSON, which fit comfortably in a 100K-token context window with room left for system prompt and output.


This prep took about four hours on day one. It was not glamorous. But the ratio of clean input to useful output is roughly linear — garbage in still gives you garbage out even when the model is state-of-the-art.

The Exact Prompt (Copy, Paste, Adapt)

Here's the prompt we used. It's long by design — specificity beats brevity for tabular reasoning tasks:

You are a senior customer-success strategist analyzing our CRM export.
Below is a JSON array of customer records with these fields:
[account_name, industry, employee_count, annual_revenue_band,
 last_login_date, tickets_open_90d, tickets_closed_90d, csat_avg_12mo,
 renewal_date, primary_contact_email, department_tags]

Your task is to produce a customer-segmentation playbook. Follow
these rules strictly:

1. Identify 5 distinct segments that maximize revenue opportunity.
   Consider at minimum: recency of engagement (last_login_date),
   service load (tickets_open_90d vs tickets_closed_90d),
   satisfaction trajectory (csat_avg_12mo), and time-to-renewal
   (renewal_date).

2. For each segment, output a JSON object with:
   - segment_name: 3-5 word label that a sales rep can say out loud
   - size: number of accounts in this chunk that fit the profile
   - signature_pattern: one sentence describing what makes these
     customers distinct (e.g., "high usage but declining CSAT —
     classic expansion-then-churn risk")
   - revenue_hypothesis: your best estimate of per-account annual
     revenue potential for this segment, with a one-line rationale.
     Use a format like "$120K/yr (mid-market SaaS benchmark, 8% 
     YoY growth in industry)"
   - top_accounts: the 5 accounts most likely to convert or expand,
     with account_name and primary_contact_email only — do NOT 
     fabricate emails not present in the data
   - call_script: a 4-6 sentence opening script for an outbound
     touch that references observable signals from their record
     (login recency, ticket volume, CSAT) without inventing facts

3. At the end of all segments, output one "risk_flags" array listing
   any accounts where data looks inconsistent or possibly stale —
   e.g., high revenue band but no logins in 6 months. Flag these 
   for human review before reps contact them.

4. Do not invent field values. If a field is null/missing, note it
   as "unknown" rather than guessing.

5. Output format: valid JSON only. No markdown fences, no 
   commentary outside the JSON.

Here are the records for this chunk:
[JSON_DATA_HERE]

Three things about this prompt deserve emphasis:


It forces evidence-based output. The "do not invent field values" instruction sounds trivial until you've seen an LLM confidently fabricate a customer's email address or CSAT score. We caught three hallucinated emails in our first run and added the constraint.


It asks for why in addition to what. revenue_hypothesis with rationale keeps the model honest about its own confidence level. When we reviewed outputs, segments where the rationale was vague ("these customers look important") were the ones that most often needed rework. Segments where the rationale cited specific numbers from the records held up under scrutiny 90% of the time.


It includes a human-review escape hatch. The risk_flags array is not optional — it's how we built trust in the output. Reps read the playbook knowing that flagged accounts were pre-screened by us, which lowered adoption friction dramatically.

The Iteration Loop (Where the Real Work Happens)

The prompt above was version 3. Version 1 asked for "segments" and got back four overlapping buckets with no scripts. Version 2 added the script requirement but produced call openings so generic that our head of sales said they could've been in a HubSpot template from 2014. Version 3 — the one above — was the first where reps actually said "yes, I'd open this email."


The iteration pattern: run prompt → read output critically for 20 minutes → identify what's missing or invented → patch the prompt with one specific constraint → rerun on a smaller test chunk (1,000 records) → verify → expand to full chunks.


We did four of these cycles in about five hours. The key insight: don't rewrite the whole prompt each time. Add one targeted constraint at a time so you can attribute which change actually helped. This is basic experimental hygiene that most people skip when working with LLMs because it feels slower than just asking the model to "do better."

Validating Output (The Part Most Tutorials Skip)

LLM output on structured data looks plausible by construction — the format is right, the tone is right, and 95% of the values are probably correct. The other 5% is where you lose money or trust. Here's how we validated:


Spot-checks against source. We picked 20 accounts from each segment and pulled their raw CRM records to verify every field cited in the output. Hit rate was 94/100 — close enough for a playbook, not close enough for an automated email blast.


Blind test with reps. We gave three salespeople the final playbook (with account names redacted) and asked them to identify which segments they'd prioritize and why. Two of three picked the same top two segments independently, which told us the logic was legible to non-analysts — a critical property for adoption.


A/B on a small batch. We ran 40 outbound touches using the scripts vs. 40 using our old templated approach over one week. The playbook-scripted group got a 31% response rate vs. 12%. That single number is what sold leadership on scaling it to all six chunks.

Scaling Beyond One Chunk

Once the prompt worked on a 1,000-record test set and validated on 8,000 records, scaling was straightforward: loop over the six chunks, run each through the model, collect outputs, merge segment definitions (since accounts appear in only one chunk after deduplication), and aggregate.


Total compute cost for the full 47K-record run: about $14 in API tokens on a mid-tier LLM. Total human time across both days: roughly 14 hours of focused work by two people — one on data prep, one on prompt iteration and validation. Compared to the six-week consultant project we'd budgeted for originally, this was about 2% of the cost and 30x faster.


One caveat worth stating plainly: the model is not doing analytics in the classical sense. It's not fitting a regression or running a cohort analysis. What it is doing is pattern-matching over tabular data with strong language understanding, which for business-segmentation tasks turns out to be surprisingly close to what a human analyst would do — just faster and more consistent.

A Small Chart: Where the $1.2M Came From

Segment

Accounts Contacted

Response Rate

Closed Deals

Attributed Revenue

High-Usage / Declining CSAT

148

34%

6

$512,000

Pre-Renewal (90-day window)

112

29%

5

$387,000

Underutilized Feature Set

96

24%

4

$254,000

New Industry Expansion Fit

61

18%

2

$148,000

Dormant but High-Revenue-Band

23

15%

1

$109,000

Total

440

~26%

18

$1.41M pipeline / $1.2M closed

The top segment — high-usage customers with declining CSAT — is a classic "they love you but are actively looking for alternatives" profile. The prompt surfaced this pattern because it was instructed to weigh all four signals together, not any single metric in isolation. A traditional dashboard would show each metric separately and leave the synthesis to whoever's reading it at 5:45 PM on a Friday.

Adaptation Guide: Your CRM, Your Industry

The prompt above is SaaS-flavored (logins, tickets, CSAT). Swap those four fields for your domain equivalents:

  • E-commerce: page_views_30d, cart_abandon_rate_30d, order_value_avg_12mo, return_rate

  • B2B Services: site_visits_90d, proposal_stage, contract_value_band, project_completion_pct

  • Consumer App: dau_wow_trend, subscription_tier, feature_adoption_count, support_contacts_90d

The structural skeleton — segments with rationale + top accounts + call script + risk flags — generalizes cleanly. Change the field list and the interpretation logic; keep everything else.


One more adaptation note: if your records include PII beyond what you'd want in a prompt (full names, phone numbers, addresses), strip them into a separate lookup table that only your reps can access after the model has done its reasoning on the anonymized set. We kept emails and account names since they were operationally necessary; we stripped everything else.

What This Pattern Is Good For — And Not For

Good for:

  • Segmenting large tabular datasets into actionable groups

  • Drafting personalized outreach at scale (with human validation)

  • Finding non-obvious correlations across many fields that no single dashboard column would show

  • Turning "our data" into "our story" in a format stakeholders can act on

Not for:

  • Financial reporting or anything where precision is contractual

  • Real-time decisioning (latency and cost don't work out)

  • Tasks requiring true statistical inference (use a stats library, not an LLM)

  • Any pipeline where hallucination has high cost (validate every fact)

The pattern is: clean input + specific prompt + validation loop = business action in days instead of months. That's the whole trick. There's no secret model or exotic technique — just disciplined prompting applied to data you already own, with enough skepticism to catch what the model confabulates.

Closing Thought

The $1.2M figure is one company's outcome on one dataset. Your number will be different because your customers are different and your signals are different. But the shape of the work — prep, prompt, iterate, validate, deploy — is nearly universal for any team sitting on a relational data asset they're underusing.


You don't need a data science team to start. You need one good person, four hours of cleanup time, two days of iteration budget, and the willingness to treat LLM output as a first draft rather than a final answer. That's all it takes to go from "we have 47K records" to "here's exactly who to call tomorrow morning."


The prompt is in this article. The CRM is already on your server. The only remaining variable is whether you'll run it before the weekend ends. 🚀