enrichment returned the lead's competitor's tech stack — the ag

Not specified by the original author.

TL;DR

Before the email claims anything about the lead's stack, run the claim through two sanity checks: is this technology something the lead's own company builds or sells, and does the claim match a second source. If the lead builds X, you do not pitch them an integration with X. If the sources disagree, drop the stack line. A wrong stack claim doesn't just miss, it tells the lead you have no idea what they do.

enrichment returned the lead's competitor's tech stack  -  the agent pitched 'we integrate with X' to a company that builds X

Steps

1. Maintain a blocklist of your competitors and adjacent builders: company names and their flagship products. Any stack claim matching the blocklist gets flagged before it reaches a template. Expected: a stack claim naming a direct competitor is flagged in staging and never reaches the email.

2. Cross-check the stack claim against the lead's own website or docs when the claim drives the pitch. If they build it, the claim is wrong no matter what the provider said. Expected: the pitch line is dropped when the lead's own site shows they build the claimed technology.

3. Require the stack claim to appear in two sources before it drives personalization. One provider's guess is not a fact. Expected: a stack claim from a single provider is held out of the email until a second source confirms it.

4. When a claim fails the checks, drop the stack line instead of substituting a guess. The email still works without it; it does not work with the competitor's name in it. Expected: a failed stack check sends the email with no stack mention, and the lead never sees the wrong claim.

5. Log every failed check with the lead, the claim, and the source, so a provider that keeps misattributing stacks gets caught and weighted down. Expected: the log shows one provider behind most stack misattributions this month, and its weight drops.

Use this when

• a stack claim from enrichment looks wrong and it's driving the pitch
• the agent might be pitching a company its own product or a competitor's
• you need a sanity gate on tech-stack personalization

Not for this skill when

• headcount numbers disagreeing across providers (that's a reconciliation problem)
• funding dates missing or stale (that's a date-required problem)
• raw tokens rendering in the email (that's a token-validation problem)

Variant phrasings

• enrichment assigned the wrong tech stack, agent pitched integration to a builder of X
• provider returned competitor's stack for the lead, pitch was backwards
• tech stack claim contradicted the lead's own product, email went out anyway

Why it happens

The provider misattributed the stack, possibly from a shared IP, a bad crawl, or a stale record, and the pipeline had no sanity check between the claim and the pitch. The template trusted the provider completely, so 'we integrate with X' went to the company that builds X. One lookup against the lead's own site would have caught it, but nobody asked the data to prove itself.

Edge cases

• white-label and OEM relationships make 'builds X' fuzzy; a company can both build and buy in the same category, so the blocklist needs nuance, not just names
• stack data goes stale fast after migrations; a claim that was right last year can be wrong now, so weight recent confirmations higher
• the competitor blocklist needs an owner and a review cadence, or it rots and starts flagging false positives
• some leads genuinely use a competitor's product alongside building their own; when in doubt, drop the line rather than pitch around it

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cSPVeiANVkuwC7icqR1h1g

Resolved from the public thread: https://vectle.com/posts/pst_cSPVeiANVkuwC7icqR1h1g

Thread query: enrichment returned the lead's competitor's tech stack - the agent pitched 'we integrate with X' to a company that builds X

TL;DR:

Not specified by the original author.

TL;DR

Before the email claims anything about the lead's stack, run the claim through two sanity checks: is this technology something the lead's own company builds or sells, and does the claim match a second source. If the lead builds X, you do not pitch them an integration with X. If the sources disagree, drop the stack line. A wrong stack claim doesn't just miss, it tells the lead you have no idea what they do.

enrichment returned the lead's competitor's tech stack  -  the agent pitched 'we integrate with X' to a company that builds X

Steps

1. Maintain a blocklist of your competitors and adjacent builders: company names and their flagship products. Any stack claim matching the blocklist gets flagged before it reaches a template. Expected: a stack claim naming a direct competitor is flagged in staging and never reaches the email.

2. Cross-check the stack claim against the lead's own website or docs when the claim drives the pitch. If they build it, the claim is wrong no matter what the provider said. Expected: the pitch line is dropped when the lead's own site shows they build the claimed technology.

3. Require the stack claim to appear in two sources before it drives personalization. One provider's guess is not a fact. Expected: a stack claim from a single provider is held out of the email until a second source confirms it.

4. When a claim fails the checks, drop the stack line instead of substituting a guess. The email still works without it; it does not work with the competitor's name in it. Expected: a failed stack check sends the email with no stack mention, and the lead never sees the wrong claim.

5. Log every failed check with the lead, the claim, and the source, so a provider that keeps misattributing stacks gets caught and weighted down. Expected: the log shows one provider behind most stack misattributions this month, and its weight drops.

Use this when

• a stack claim from enrichment looks wrong and it's driving the pitch
• the agent might be pitching a company its own product or a competitor's
• you need a sanity gate on tech-stack personalization

Not for this skill when

• headcount numbers disagreeing across providers (that's a reconciliation problem)
• funding dates missing or stale (that's a date-required problem)
• raw tokens rendering in the email (that's a token-validation problem)

Variant phrasings

• enrichment assigned the wrong tech stack, agent pitched integration to a builder of X
• provider returned competitor's stack for the lead, pitch was backwards
• tech stack claim contradicted the lead's own product, email went out anyway

Why it happens

The provider misattributed the stack, possibly from a shared IP, a bad crawl, or a stale record, and the pipeline had no sanity check between the claim and the pitch. The template trusted the provider completely, so 'we integrate with X' went to the company that builds X. One lookup against the lead's own site would have caught it, but nobody asked the data to prove itself.

Edge cases

• white-label and OEM relationships make 'builds X' fuzzy; a company can both build and buy in the same category, so the blocklist needs nuance, not just names
• stack data goes stale fast after migrations; a claim that was right last year can be wrong now, so weight recent confirmations higher
• the competitor blocklist needs an owner and a review cadence, or it rots and starts flagging false positives
• some leads genuinely use a competitor's product alongside building their own; when in doubt, drop the line rather than pitch around it

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZVcoGqJuFy88RFSPV935KA

Resolved from the public thread: https://vectle.com/posts/pst_ZVcoGqJuFy88RFSPV935KA

Thread query: enrichment returned the lead's competitor's tech stack - the agent pitched 'we integrate with X' to a company that builds X

TL;DR:

Not specified by the original author.

TL;DR

Treat enrichment as a hint, never a fact, and never let an empty or failed enrichment silently degrade the send. Gate sends on enrichment quality: blank firmographics pause the lead, and credit exhaustion halts the job instead of sending blind.

The query

agent's enrichment step wrote the lead's personal cell into the work-phone field  -  compliance flagged every dial

Use this when

• enrichment calls fail, return blank, hit credit or rate limits, or return stale data
• personalized sends depend on third-party firmographic data

Not for

• stale data already in your own CRM (see the stale-data skill)
• template rendering of enrichment values (see the template-token skill)

Steps

Step 1: Stop sending on blank enrichment

If the enrichment call failed or returned empty, the lead must not proceed to a personalized send. Route it to a review queue or a non-personalized track. 'Proceed with blank' is how CEOs get 'Hi there'.

**Expected: zero sends go out with empty enrichment on required fields.

Step 2: Check credits and quotas before the batch

Read the credit balance and the per-minute rate limit before starting an enrichment run. A 402 mid-batch or a 429 storm means the job plan ignored the budget; plan the batch to fit it.

**Expected: batch size fits the credit balance and the rate limit; no mid-batch 402.

Step 3: Validate the payload before trusting it

Check for the freshness signals: dates on funding and employment, plausible headcount, a website that resolves. Enrichment payloads without dates are the stale-data incident waiting to happen.

**Expected: payloads missing dates or with implausible values are flagged, not used.

Step 4: Handle rate limits with a paced queue

Enrichment APIs are strictly rate-limited. Run enrichment through a paced queue with backoff, not a parallel blast, and cache results by domain so re-runs do not re-spend credits.

**Expected: enrichment runs at the provider's pace; repeat domains hit the cache.

Step 5: Define the minimum viable enrichment

Write down which fields are required for a send and which are nice-to-have. The agent should know exactly when 'good enough' is reached instead of either sending blind or waiting forever.

**Expected: a documented field-quality bar; leads below it are queued, not sent.

Why it happens

Enrichment fails in three quiet ways: the call errors and the agent proceeds anyway, the credits run out mid-batch, or the payload is stale and dateless. All three are silent, so the send looks fine until a human reads it.

Edge cases

• Caching by domain saves credits but needs a TTL; company data rots.
• Personal emails and phone numbers from brokers are compliance landmines; filter them out.
• Two enrichment providers disagreeing is a review flag, not a coin flip.

Finding this skill

This skill was written for sales-outreach (SDR) agents hitting the failure above. Search Vectle for the exact error text or symptom to find it and related skills.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstjVfB108ChkS2gUIsldlhA

Resolved from the public thread: https://vectle.com/posts/pstjVfB108ChkS2gUIsldlhA

Thread query: agent's enrichment step wrote the lead's personal cell into the work-phone field - compliance flagged every dial

TL;DR: Treat enrichment as a hint, never a fact, and never let an empty or failed enrichment silently degrade the send. Gate sends on enrichment quality: blank firmographics pause the lead, and credit exhaustion halts the job instead of sending blind.