agent personalized emails with the lead's old company after a job change - enrichment refreshed but the template used...

TL;DR

Timestamp your enrichment cache and never let the template read a row you can't date. When fresh enrichment comes back with a different employer than the cached row, the fresh row wins and the stale one gets flagged. For job-change-prone fields like company and title, re-validate against the fresh pull at send time, or at least compare the cached value to the new one and pick the newer. Personalizing with the old company tells the lead you weren't paying attention.

agent personalized emails with the lead's old company after a job change  -  enrichment refreshed but the template used the cached row

Steps

1. Store an enriched_at timestamp on every cached enrichment row, and set a max age for volatile fields like company and title. Anything older gets refreshed before a send.

Expected: a cached row from 6 months ago is refreshed automatically before the template reads it; the send uses current data.

1. When a fresh enrichment pull returns, diff it against the cached row. If the employer or title changed, use the fresh value and mark the cached row stale.

Expected: a lead who changed jobs shows the new company in the next email, and the old row is marked stale in the cache.

1. Cross-check the employer against a second signal when you can, like the lead's current headline or recent company page. One stale source plus one fresh source beats trusting the cache alone.

Expected: the template's company value matches the fresh pull, not the 8-month-old cached row.

1. Log every stale-row detection with the lead and the field, so a pattern of stale company values points you at a cache TTL that's too long.

Expected: the stale log shows company mismatches clustering on rows older than 30 days, and you shorten the TTL.

1. If the fresh pull and the cache disagree and you can't resolve it, drop the personalization line rather than guessing. No company mention beats the wrong company mention.

Expected: an unresolvable mismatch sends the email without the company line instead of with the wrong one.

Use this when

• personalization uses an old employer or title after the lead changed jobs
• the enrichment cache and the fresh pull disagree and the template trusts the cache
• you need a freshness policy for volatile enrichment fields

Not for this skill when

• enrichment data that is wrong at the source in both the cache and the fresh pull (that's a provider problem)
• templates pulling from the wrong field entirely (that's a field-mapping problem)
• job-change detection as a trigger event for new sequences (that's a signal problem, not a staleness problem)

Variant phrasings

• template used cached company row after lead changed jobs, email named old employer
• stale enrichment cache personalized with previous company, fresh pull ignored
• lead congratulated on role at company they left, cached row outdated

Why it happens

The cache held the lead's old employer from months ago, and the template read the cached row directly. A fresh enrichment pull had the new company, but nothing compared the two or invalidated the old row, so the email went out naming a company the lead no longer works at. Caches without timestamps and without invalidation are just old data wearing a fresh label.

Edge cases

• some providers only refresh on request, so 'fresh pull' still returns their own stale cache; check the provider's data vintage, not just your cache age
• a lead with two concurrent roles (advisor plus full-time) can look like a job change; don't overwrite the primary employer on a single conflicting signal
• refreshing every row at send time can blow your enrichment budget; prioritize volatile fields and high-value segments
• name variations (acronym vs full name) can fake a mismatch; normalize company names before diffing

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_A09LM-hgaaPoXdXnNqljWg