$ man pain-point-signal

Pain Point Signal

A data point or observation that indicates a problem the contact's company is facing. Recent leadership change. Outdated tech stack. Competitor mention in job postings. Declining search traffic. Not a guess — a verifiable signal.

Generic pain points don't work. "I know scaling is hard" gets ignored. Specific pain signals get replies. If I can point to a real, observable problem (your company just posted 5 SDR roles, your site runs on outdated infrastructure, your competitor is outranking you in search), the email feels less like a cold pitch and more like "how did you know?" the signal has to be real. if I can't prove it from research, I don't use it.

I pull pain signals from multiple sources and layer them. LinkedIn post scraping (Apify) shows what the company is talking about publicly. Semrush shows search traffic drops or competitor gaps. Job postings show hiring urgency. Tech stack data shows legacy tools. and now Exa — I built a signal detection script that sweeps 6 signal types per company: funding activity, M&A activity, hiring signals, market expansion, technology adoption, and customer complaints. it ran across 73 companies and detected 342 signals in one session. each signal gets categorized, timestamped, and matched to a pain point in the partner's pain library. I feed those signals into a research prompt that generates the {pain_point} variable for email sequences. the prompt maps signals to industry-specific pain language — OTIF chargebacks for CPG, deployment complexity for enterprise IT, tool sprawl for tech companies. the output is a one-sentence pain observation that feels researched, not generic.