» The DIY Intelligence Layer: When the Budget Says No, the Stack Says Yes

Mid-market teams increasingly know what intelligence they need in their GTM stack. Buying group visibility. Intent signals. Account change detection. The ability to qualify based on behavior, not just firmographics.

The problem isn’t strategy. It’s budget.

Enterprise GTM platforms bundle intelligence into the product. AI is making it possible for mid-market teams to assemble pieces of that intelligence layer themselves.

Most of the platforms that solve this natively are expensive. And for many teams, not realistic right now. But here’s what we’re seeing across clients: AI can replicate a surprising amount of that intelligence layer using tools already in the stack. Not perfectly. Not at enterprise scale. But well enough to surface insights that were completely invisible before.

This past quarter, three scenarios across multiple clients all surfaced the same constraint:

1. Factoring account-level growth signals into qualification logic. Expansions, acquisitions, and other public growth indicators were meaningful, but the system had no way to recognize or act on them.
2. Translating inconsistent job titles into structured buying roles. “VP of Innovation,” “Head of Digital,” and “Director of Transformation” might all influence a purchase, but without interpretation, the system treats them as unrelated strings of text.
3. Using demographic data and purchase history to identify high-probability premium buyers. The data existed, but it was not being evaluated in a way that surfaced true likelihood to buy.

Different industries. Different business models. Same problem: the system can’t think beyond its fields.

So instead of defaulting to “we need a new platform,” we asked a simpler question: is there a practical way to use AI to solve this inside the stack we already have?

I’ll walk through how we approached each one, using Tegrita’s ICP as a safe example so you can see the mechanics clearly. Because sometimes the constraint isn’t the strategy. It’s the imagination around how to execute it.

Use Case 1: Reading the Room on Account Growth

You have a list of target accounts. Some of them are in the middle of something significant: an acquisition, a leadership transition, a reorg, a platform overhaul. Any one of those moments could make them ready to buy.

The problem is that sales teams typically catch these signals during account research. And no one has time to manually research every account, every day. So the signal gets missed, and accounts that are actively in a change cycle stay buried in a list with no urgency attached.

To test a practical workaround, I used Tegrita’s ICP as the example, taking a list of accounts and using an AI enrichment in Clay to scan for any recent public signals (press releases, news coverage, LinkedIn posts, announcements) that would indicate the kind of business change that typically triggers a need for what Tegrita does.

The Clay table does three things for each account:

1. Identifies and categorizes the type of change detected (acquisition, leadership hire, reorg, tech investment, etc.)
2. Provides a confidence level that the AI is correctly interpreting the change. When limited information is available, it may be inferring, and we want to know that.
3. Produces a likelihood score assessing how probable it is that this account is now positioned to engage.

The output isn’t perfect. AI-based signal detection has noise. But if integrated with the CRM it can consistently surfaces accounts that sales teams would not have caught until much later, enabling earlier outreach, better SDR prioritization, and more relevant messaging when the timing actually matters.

PROMPT 1 — Company Trigger Signal Enrichment

Below is a templated version of the prompt I used in Clay. Editing the sections in brackets throughout will allow you to customize for your organization.

You are a B2B sales intelligence researcher. Search for recent news releases, 
press releases, social media posts, and online announcements from the last 
[TIMEFRAME] related to the company: {{company_name}} (website: {{company_website}}).

Your goal is to identify whether this company is experiencing any of the 
following business transition events:

[LIST YOUR TRIGGER EVENTS HERE — e.g.:
1. [Trigger Event Name] – [One sentence describing what this looks like]
2. [Trigger Event Name] – [One sentence describing what this looks like]
...add as many as are relevant to your ICP]

If you find a relevant trigger event, return ONLY a valid JSON object with 
these four fields:

{
  "trigger_category": "The name of the matching category from your list, 
    or 'None Identified' if no match found",
  "change_summary": "A 2–3 sentence plain-language summary of what is 
    happening and why it signals a transition moment. Include the source 
    type and approximate date if known.",
  "relevance_score": "High, Medium, or Low — based on how urgently this 
    transition is likely to create a need for [DESCRIBE YOUR SERVICE OR 
    SOLUTION HERE]. Use High if the trigger typically forces immediate 
    decisions, Medium if it signals likely future need, Low if it is 
    early-stage or speculative.",
  "confidence_level": "High, Medium, or Low — based on how credible and 
    direct the source is. High = direct company announcement or verified 
    press release. Medium = reputable trade publication or executive social 
    post. Low = inferred from indirect signals or a single unverified source."
}

If no trigger is found, return:
{
  "trigger_category": "None Identified",
  "change_summary": "No relevant trigger signals found in the last [TIMEFRAME].",
  "relevance_score": "N/A",
  "confidence_level": "N/A"
}

Return only the JSON object. No explanation, no markdown, no extra text.

Use Case 2: Making Job Titles Mean Something

This one comes up constantly in B2B environments with complex buying committees.

You have a contact list. The titles are all over the place. “VP of Innovation.” “Director of Digital Transformation.” “Head of Revenue Excellence.” “Growth Operations Lead.” These people may all play meaningful roles in a purchase decision, but without a way to interpret what they actually do relative to the buying process, the system treats them as unrelated text strings.

(I still have flashbacks to building contact washing machine programs in marketing automation with an endless list of exact match and “contains” rules just to normalize titles into something usable:

VP Marketing

VP of Marketing

Vice President Marketing

Marketing Vice President

Vice President, Marketing

LOL… We’ve come a long way.)

For this use case, I built a Clay table using a fictional contact list with varied and intentionally inconsistent titles. The AI column takes each title and maps it to one of five structured buying roles:

• Decision Maker: has authority to approve the purchase
• Key Stakeholder: directly impacted, strong influence on the decision
• Stakeholder: affected but not a primary driver
• Influencer: shapes opinion without formal authority
• Gatekeeper: controls access to decision makers or the process itself

When every contact has a structured role, the downstream value compounds quickly. You can sequence differently by persona, write copy that speaks to where someone actually sits in the decision, and build buying group visibility across an account even when no one on the list has an obvious title. That’s a meaningful improvement in how a team works a list.

PROMPT 2 — Job Title Normalization

You are a sales intelligence analyst. Your job is to interpret a contact's 
job title and return two normalized classification fields.

Job Title: {{job_title}}

---

STEP 1 — Determine FUNCTION:
Classify the job title into exactly one of these functions:

[LIST YOUR FUNCTIONS HERE — e.g.:
- [Function Name] – Includes roles such as [example titles]
- [Function Name] – Includes roles such as [example titles]
...add a catch-all "Other" category at the end]

---

STEP 2 — Determine ROLE IN PURCHASE PROCESS:
Apply these rules in order — use the first rule that matches:

[LIST YOUR RULES HERE IN PRIORITY ORDER — e.g.:
1. If Function is [X] AND seniority is [Y] → "[Role Label]"
2. If Function is [X] OR [Y] → "[Role Label]"
...end with a catch-all rule]

Seniority reference:
- Senior/Executive level = [LIST THE TITLES YOU CONSIDER SENIOR — e.g., VP, 
  SVP, EVP, C-Suite, Chief, President]
- All others = non-senior

---

Return ONLY a valid JSON object with exactly these two fields:

{
  "function": "One of: [YOUR FUNCTION LIST]",
  "role_in_purchase_process": "One of: [YOUR ROLE LIST]"
}

No explanation, no markdown, no extra text. JSON only.

Use Case 3: Turning Customer History Into Outbound Intelligence

The third use case required a fictional scenario because the real client context was too specific to share. But the underlying problem shows up regularly in event or ticket driven businesses, entertainment, and consumer-to-business crossover models.

Here’s the setup: ACME & Co. is a fictitious event management company that runs social events across many different organizations. Each event offers three ticket classes: General Admission, Premium, and VIP. They have a customer list with purchase history across all events and wanted to use it to drive outbound for the high-ticket items.

Their outbound team needed to answer two different questions about the same contact list:

1. Should we reach out to sell this person a Premium or VIP ticket to other relevant events?
2. Does their professional role make them a B2B opportunity, a company we could pitch event management services to?

Here’s the wrinkle: some of the data was already there (purchase history, ticket class, event attendance) but the rest wasn’t. Because customers buy tickets as individuals, job title and company aren’t captured at registration. That required an enrichment step before the AI could do its job.

Once enriched, the Clay table evaluates three inputs together: job title, tickets purchased in the past year, and typical ticket class. From that combination, it generates a B2C upsell flag, a B2B opportunity flag, a priority score to sequence outbound calls, and a logic column so the rep understands the reasoning before they dial.

The result is a prioritized call list built from data that already existed, just never connected.

PROMPT 3 — B2C Attendee Opportunity Scoring

You are a sales intelligence analyst. Using the contact data below, evaluate 
this person for two independent sales opportunities and assign a call priority.

CONTACT DATA:
- Name: {{name}}
- Job Title: {{job_title}} (use "-" if unknown)
- [DATA FIELD]: {{variable}} 
- [DATA FIELD]: {{variable}}
[ADD ANY ADDITIONAL DATA FIELDS YOU HAVE — purchase history, spend level, 
engagement data, demographic info, etc.]

---

STEP 1 — Classify Job Function (if title is not "-"):
[LIST YOUR FUNCTION CATEGORIES AND WHAT TITLES BELONG TO EACH]
- [Category Name]: [example titles]
- [Category Name]: [example titles]
- No Title: Job title is "-"

STEP 2 — Determine Seniority (if title is not "-"):
- Senior/Executive: [LIST THE TITLES YOU CONSIDER EXECUTIVE LEVEL]
- Non-Executive: [LIST OR DESCRIBE WHAT FALLS BELOW YOUR THRESHOLD]

---

STEP 3 — Evaluate [OPPORTUNITY TYPE 1 — e.g., Premium Product Buyer]:
Answer Yes if ANY of the following are true:
[LIST YOUR QUALIFICATION RULES FOR THIS OPPORTUNITY — e.g.:
- [Seniority] in [Function] + [behavioral/data condition] → Yes
- [Data condition alone, no title required] → Yes]
Otherwise: No

STEP 4 — Evaluate [OPPORTUNITY TYPE 2 — e.g., B2B Opportunity]:
Answer Yes if ANY of the following are true:
[LIST YOUR QUALIFICATION RULES FOR THIS OPPORTUNITY]
Otherwise: No

STEP 5 — Determine CALL PRIORITY:
Apply the first matching rule:

High: [DEFINE WHAT COMBINATION OF SIGNALS = HIGH PRIORITY]
Medium: [DEFINE WHAT COMBINATION OF SIGNALS = MEDIUM PRIORITY]
Low: [DEFINE WHAT COMBINATION OF SIGNALS = LOW PRIORITY]
None: Both opportunity flags are No

---

Return ONLY a valid JSON object with exactly these four fields:

{
  "[opportunity_type_1]": "Yes or No",
  "[opportunity_type_2]": "Yes or No",
  "call_priority": "High, Medium, Low, or None",
  "scoring_rationale": "One sentence explaining the key factors that drove 
    the call priority."
}

No explanation, no markdown, no extra text. JSON only.

The Intelligence Layer Already Exists. It Just Needs Logic.

The real takeaway from all three of these isn’t about Clay specifically. It’s about what AI makes possible inside the stack you already have. What these builds demonstrate is that AI can now act as a thin logic layer connecting data that already exists, surfacing signals that would otherwise stay invisible.

The barrier to entry is low. Each of these was a relatively quick build. The harder part is getting the requirements right: figuring out which signals matter, how to define roles for your context, what combination of inputs produces a useful output. That thinking takes time. The build itself did not.

This is not an argument against buying more robust solutions. Purpose-built platforms for intent data, buying group modeling, and predictive scoring are more sophisticated, more scalable, and worth it when the business has the budget and maturity to absorb them.

But for teams under a “no new tech” mandate or working with tighter budgets, the answer to “we need better intelligence” does not have to be “then we have to wait.”

A skilled practitioner, a thoughtful prompt, and a tool like Clay, Zapier, Make, N8N, and others can go a long way.

The limiting factor isn’t tooling. It’s how clearly you define the signals that matter.

I’m curious what others are building to fill intelligence gaps in their stack. What have you hacked together that actually works?