Target ICP Classification & VIP Lead Notification Workflow

1. Workflow purpose

This workflow is designed to process newly received or updated lead records, enrich available lead and company data, classify the lead against predefined Target ICP segments, calculate the confidence level of the match, and notify the sales team when the lead qualifies as a high-priority or VIP opportunity.

The workflow acts as a lead intelligence and prioritization layer. Its purpose is not simply to update CRM records - it creates a structured decision engine that helps the sales team identify the highest-value opportunities faster, while protecting CRM data quality, reducing unnecessary enrichment costs, and avoiding noisy sales notifications.

This workflow focuses only on:

• Lead intake
• Exact record lookup
• Data normalization
• Enrichment status check
• Enrichment lock control
• Lead and company enrichment
• Website/company profile parsing
• Data sanitization
• Target ICP classification
• ICP confidence scoring
• VIP lead detection
• Sales manager notification
• CRM record update
• Audit logging

Duplicate merge handling and lead source attribution cleanup are handled in separate workflow documents.

2. Core workflow principle

The main rule of this workflow is: lookup first, lock second, normalize third, enrich only when needed, classify only when enough data exists, and notify only when the decision is supported by strong evidence.

No enrichment, website scraping, classification, CRM update, VIP notification, or outreach sequence activation should happen before the system performs the required lookup steps:

[LOOKUP/FETCH_CONTACT_EXACT]
[LOOKUP/FETCH_COMPANY_EXACT]
[LOOKUP/FETCH_EXISTING_ENRICHMENT_STATUS]
[LOOKUP/FETCH_EXISTING_CLASSIFICATION_STATUS]
[LOOKUP/FETCH_EXISTING_OWNER]
[LOOKUP/FETCH_ACTIVE_DEALS]

This prevents unnecessary enrichment costs, duplicate processing, bad CRM overwrites, and premature sales notifications.

3. Workflow scope

Included in this workflow

This workflow includes: lead intake validation, exact contact and company lookup, existing record check, existing enrichment status check, enrichment lock handling, data normalization, contact enrichment, company enrichment, website content extraction, company profile extraction, website scraping fallback logic, residential proxy fallback for public website scraping, extracted data sanitization, keyword direction generation, target ICP classification, ICP confidence scoring, VIP lead detection, CRM field update, sales manager notification, sales follow-up task creation, and audit vault logging.

Excluded from this workflow

The following logic is intentionally excluded and should be documented separately:

• Duplicate lead merge logic
• Possible duplicate alerting
• Contact merge rules
• Company merge rules
• Lead source attribution cleanup
• UTM cleanup
• Original/latest source correction
• Historical attribution conflict handling
• Manual import cleanup
• Bulk CRM hygiene

This workflow may detect that a possible duplicate exists, but it does not perform the merge. It can pause, flag, or route the record to the duplicate workflow.

4. Primary trigger

[TRIGGER: LEAD_RECEIVED_OR_UPDATED]

The workflow can be triggered when:

• A new lead is submitted through a web form
• A lead is received through an integration
• A lead is captured from an email-based process
• A lead is created manually
• A lead is imported
• A company/contact enrichment event is completed
• A lead record is updated with new classification-relevant data

5. Required input fields

The workflow should attempt to collect the following fields at intake.

Contact fields

first_name · last_name · email · phone · job_title · linkedin_profile_url

Company fields

company_name · company_domain · company_website · company_linkedin_url · company_industry · company_size · company_country · company_description

System fields

lead_id · company_id · record_owner · lifecycle_stage · enrichment_status · classification_status · last_enriched_at · last_classified_at · classification_version

Context fields

lead_source · form_name · submission_message · integration_source · created_at · updated_at · form_intent

6. Step 1: Raw intake & exact lookup

The first step is to capture the raw inbound payload exactly as received.

[CAPTURE_RAW_INBOUND_PAYLOAD]

The raw payload should be saved before any cleanup or transformation happens. Immediately after capture, the workflow performs exact lookup checks using stable identifiers:

[LOOKUP/FETCH_CONTACT_BY_EXACT_EMAIL]
[LOOKUP/FETCH_CONTACT_BY_EXACT_LINKEDIN_URL]
[LOOKUP/FETCH_COMPANY_BY_EXACT_DOMAIN]
[LOOKUP/FETCH_COMPANY_BY_EXACT_WEBSITE]
[LOOKUP/FETCH_COMPANY_BY_EXACT_LINKEDIN_URL]

Why exact lookup happens before full normalization

Full normalization should not be the first step because aggressive cleanup may change values in a way that prevents matching existing CRM records.

Example: the raw company name Acme Corp, Inc. normalizes to Acme Corp - but if the CRM record is stored as Acme Corp, Inc., a normalized-name lookup may fail.

Therefore, this workflow uses this order:

1. Capture raw payload
2. Run exact lookup using stable identifiers
3. Run lightweight cleanup for matching-safe fields
4. Normalize for enrichment, scoring, and classification

Exact lookup should prioritize email, company_domain, company_website, linkedin_profile_url, and company_linkedin_url. Company name should be treated as a weaker lookup field and should not be used alone for automatic matching.

7. Step 2: Enrichment lock & in-flight protection

Before running enrichment or website scraping, the workflow must check whether enrichment is already in progress.

[LOOKUP/FETCH_ENRICHMENT_LOCK_STATUS]

This prevents two workflow runs from enriching the same lead or company at the same time.

Required lock statuses

ENRICHMENT_NOT_STARTED · ENRICHMENT_IN_PROGRESS · ENRICHMENT_COMPLETED · ENRICHMENT_FAILED · ENRICHMENT_SKIPPED_RECENT_CACHE

Lock logic

[IF: ENRICHMENT_STATUS = ENRICHMENT_IN_PROGRESS]
   YES:
   → [WAIT_OR_EXIT_WITH_RETRY_FLAG]
   → [CREATE_AUDIT_LOG: ENRICHMENT_ALREADY_IN_PROGRESS]
   → [END_OR_RETRY_LATER]

If enrichment is not already in progress and enrichment is required, the workflow should immediately set ENRICHMENT_IN_PROGRESS - before calling enrichment APIs, scraping websites, or running any expensive external processing.

Lock expiration

The enrichment lock should have an expiration window. Recommended lock TTL: 15–30 minutes. If the lock is older than the allowed TTL, the workflow can mark it as stale:

[SET_STATUS: ENRICHMENT_LOCK_STALE]
[RETRY_ENRICHMENT]

This prevents records from being permanently stuck if a workflow fails mid-run.

8. Step 3: Normalization layer

After exact lookup and lock validation, the workflow normalizes the data for enrichment, scraping, and classification.

[NORMALIZE_CONTACT_AND_COMPANY_DATA]

The normalization process should include: lowercase email address, trim whitespace from all text fields, normalize first and last name formatting, normalize phone number where possible, normalize company domain, remove tracking parameters from website URLs, normalize LinkedIn profile URLs, normalize company LinkedIn URLs, remove duplicated punctuation, remove unnecessary symbols from company name, convert empty values into null values, and standardize country and industry values where possible.

The normalized values should be used for API payload preparation, keyword matching, classification logic, enrichment provider requests, and website parsing inputs. The raw values should still be preserved in the audit vault.

9. Step 4: Existing status & cache check

Before enrichment begins, the workflow checks whether valid enriched data already exists.

[LOOKUP/FETCH_EXISTING_ENRICHMENT_STATUS]
[LOOKUP/FETCH_EXISTING_CLASSIFICATION_STATUS]
[LOOKUP/FETCH_LAST_ENRICHED_AT]
[LOOKUP/FETCH_LAST_CLASSIFIED_AT]

When enrichment can be skipped (fresh cache)

Enrichment can be skipped if enrichment_status = ENRICHMENT_COMPLETED, and last_enriched_at is within the accepted freshness window, and required classification fields are present, and company website/domain exists, and company description or website summary exists. Recommended enrichment cache window: 90 days.

When classification can be skipped

Classification can be skipped if classification_status = ICP_MATCH_CONFIRMED, and last_classified_at is less than 90 days ago, and classification_version is current, and form_intent is not high-intent, and no new company data has been added.

When reclassification should happen

Reclassification should happen if: classification_version changed, or form_intent = demo_request, or form_intent = pricing_request, or enrichment data was updated, or company website changed, or previous classification failed, or previous status = INSUFFICIENT_DATA, or manual reclassification was requested.

This prevents unnecessary CRM rewrites while still allowing high-intent leads to be reviewed immediately.

10. Step 5: Enrichment decision logic

After lookup, lock, normalization, and cache check, the automation decides whether enrichment is required.

[IF: ENRICHMENT_REQUIRED?]

Enrichment should continue if

• The lead has never been enriched
• The company has never been enriched
• Required classification fields are missing
• Company website is missing
• Company description is missing
• Company industry is missing
• Company LinkedIn data is missing
• Existing enrichment data is outdated
• Existing ICP classification failed
• Existing status is insufficient data
• The sales team manually requested reclassification

Enrichment can be skipped if

• The lead was recently enriched
• Required company fields are already available
• ICP classification is already completed
• Classification version is current
• No new relevant information has been added
• The lead is already disqualified
• The company is already classified with high confidence

11. Step 6: Enrichment & data collection layer

If enrichment is required, the automation should collect additional information about the contact and company.

[ENRICH_CONTACT_AND_COMPANY]

The enrichment layer should attempt to retrieve: company website, company domain, company LinkedIn profile, company description, industry, company size, location, contact job title, contact seniority, contact department, contact LinkedIn profile, company keywords, public company summary, website metadata, SEO description, homepage content, and about page content if available.

The enrichment layer should not decide the ICP classification. It only collects and prepares data for the classification layer.

12. Step 7: Website & company profile parsing

Once company information is available, the workflow should parse the company website and available profile data.

[PARSE_COMPANY_WEB_PRESENCE]

The parsing layer should attempt to collect: homepage title, SEO meta description, main homepage text, about page text, product/service page text, company LinkedIn description, public company category, industry labels, technology keywords, service keywords, customer type indicators, and business model indicators.

13. Website scraping strategy

Website scraping should be treated as a resilient multi-step extraction process. The workflow should not rely only on a basic HTTP request, because many modern websites use JavaScript rendering, cookie banners, bot protection, CDN-level filtering, or single-page frameworks that return incomplete HTML.

[SCRAPE_ATTEMPT_1: STANDARD_HTTP_FETCH]
→ [IF: CONTENT_VALID?]
   YES:
   → [CONTINUE_TO_SANITIZATION]

[SCRAPE_ATTEMPT_2: RENDERED_BROWSER_FETCH]
→ [IF: CONTENT_VALID?]
   YES:
   → [CONTINUE_TO_SANITIZATION]

[SCRAPE_ATTEMPT_3: RENDERED_BROWSER_WITH_PROXY]
→ [IF: CONTENT_VALID?]
   YES:
   → [CONTINUE_TO_SANITIZATION]

[IF: ALL_SCRAPING_ATTEMPTS_FAILED]
   → [SET_STATUS: WEBSITE_PARSE_FAILED]
   → [CONTINUE_WITH_AVAILABLE_ENRICHMENT_DATA]
   → [CREATE_AUDIT_LOG]

14. Residential proxy fallback

Residential proxies should not be the default scraping method. They should be used as a fallback when standard scraping or rendered browser scraping fails due to access restrictions, geolocation-based blocking, or CDN/bot filtering.

[SCRAPE_ATTEMPT_3: RENDERED_BROWSER_WITH_RESIDENTIAL_PROXY]

When to use residential proxy fallback

Use the residential proxy fallback only when: standard_fetch_failed, or rendered fetch returned empty content, or the website returned access denied, or the website returned a bot challenge, or website content is geo-restricted, or the website blocks datacenter IP ranges.

Residential proxy requirements

The scraping layer should support: country_or_region_selection, request_timeout, retry_limit, proxy_rotation, user_agent_rotation, javascript_rendering, cookie_banner_handling, rate_limit_control, and blocked_response_detection.

Proxy guardrails

Residential proxy scraping should follow strict guardrails:

• Only scrape public company website pages.
• Do not attempt to bypass login-protected pages.
• Do not scrape private user data.
• Do not overload target websites.
• Respect robots and legal/compliance requirements where applicable.
• Use a retry limit.
• Log proxy usage in the audit vault.
• Stop scraping if the website repeatedly blocks the request.

Recommended proxy flow

[IF: STANDARD_HTTP_FETCH_FAILED]
→ [TRY_RENDERED_BROWSER_FETCH]

[IF: RENDERED_BROWSER_FETCH_FAILED]
→ [TRY_RENDERED_BROWSER_WITH_RESIDENTIAL_PROXY]

[IF: RESIDENTIAL_PROXY_FETCH_FAILED]
→ [SET_STATUS: WEBSITE_PARSE_FAILED]
→ [USE_AVAILABLE_COMPANY_DESCRIPTION_AND_ENRICHMENT_DATA]
→ [CREATE_MANUAL_REVIEW_TASK_IF_ICP_SIGNALS_EXIST]

Proxy usage audit fields

proxy_used · proxy_type · proxy_country · scrape_attempt_count · scrape_status · scrape_failure_reason · rendered_browser_used · content_length_extracted · parsed_pages_count

15. Data sanitization layer

Before classification, the automation must sanitize all extracted text.

[SANITIZE_EXTRACTED_DATA]

The sanitization layer should:

• Remove HTML tags
• Remove navigation text
• Remove footer text
• Remove cookie banner text
• Remove repeated words
• Remove unrelated boilerplate
• Remove excessive whitespace
• Convert text to lowercase for keyword comparison
• Keep a clean version for human review
• Keep a normalized version for keyword matching
• Remove irrelevant special characters
• Deduplicate repeated phrases
• Drop common menu items
• Drop legal boilerplate
• Drop newsletter/signup boilerplate

This step is important because raw website data can be noisy and may create false ICP matches.

16. Keyword direction generation

After sanitization, the automation should generate a clear keyword direction from the extracted data.

[GENERATE_KEYWORD_DIRECTION]

The keyword direction should include: strong matched keywords, weak matched keywords, negative keywords, industry keywords, product/service keywords, business model keywords, customer type keywords, role/seniority keywords, company maturity keywords, and intent keywords.

Example output:

matched_keywords:
- online casino
- sportsbook
- betting platform
- gaming operator

negative_keywords:
- news site
- affiliate blog
- job board

business_model_keywords:
- operator
- platform
- software provider

classification_direction:
- likely ICP 1: Online Casino Operator

17. Target ICP classification layer

The classification layer compares the sanitized company and contact data against predefined ICP definitions.

[ICP_CLASSIFICATION]

Each ICP segment should have its own rule group. Example segments:

• ICP 1: Online Casino Operators
• ICP 2: Platform Providers
• ICP 3: CRM / Retention / Engagement Platforms

Each ICP definition should include: required keywords, strong positive keywords, supporting keywords, negative keywords, industry indicators, business model indicators, website description indicators, company profile indicators, company category indicators, contact role indicators, and disqualification signals.

The classification layer should return both target_icp_segment and target_icp_confidence_score.

18. ICP confidence scoring

Each classification should receive a confidence score from 0 to 100.

[CALCULATE_ICP_CONFIDENCE_SCORE]

Suggested scoring structure:

Confidence levels:

19. Classification outcomes

The classification layer should return one of the following statuses:

ICP_MATCH_CONFIRMED · ICP_MATCH_PROBABLE · ICP_REVIEW_REQUIRED · ICP_NOT_MATCHED · ICP_CLASSIFICATION_FAILED · INSUFFICIENT_DATA

Status logic

20. VIP lead detection logic

After ICP classification, the workflow checks whether the lead qualifies as VIP.

[CHECK_VIP_ELIGIBILITY]

A lead should qualify as VIP only when it has both strong ICP fit and strong sales priority signal.

VIP qualification rules

A lead can be marked as VIP when: ICP confidence score >= 90, and the target ICP segment is approved for fast-track, and no disqualification flags are present, and contact data is usable, and company data is complete enough for sales action.

Optional additional rules: contact seniority is decision-maker or influencer, or the lead submitted a high-intent form, or the lead requested demo/pricing/contact, or the company matches strategic account criteria, or company size/revenue fits the sales team definition.

21. VIP scoring model

The VIP score should also be calculated from 0 to 100.

[CALCULATE_VIP_SCORE]

Suggested VIP scoring structure:

VIP status levels:

22. VIP fast-track notification flow

When a lead qualifies as VIP, the automation should notify the sales manager and create the correct follow-up action.

[VIP_FAST_TRACK_NOTIFICATION]

Notification trigger

[IF: VIP_STATUS = VIP_FAST_TRACK]

Notification actions

[ASSIGN_STATUS: VIP_FAST_TRACK]
[ASSIGN_PRIORITY_OWNER]
[CREATE_SALES_FOLLOW_UP_TASK]
[NOTIFY_SALES_MANAGER]
[NOTIFY_ASSIGNED_OWNER]
[ACTIVATE_RELEVANT_OUTREACH_SEQUENCE]
[UPDATE_CONTACT_RECORD]
[UPDATE_COMPANY_RECORD]
[CREATE_AUDIT_LOG]

23. Two-tier notification model

VIP notification should not rely only on a CRM task - a CRM task can be missed, ignored, or buried inside a busy sales queue. Therefore, VIP Fast-Track leads should trigger two types of notifications.

Tier 1: CRM-based action

[CREATE_SALES_FOLLOW_UP_TASK]
[ASSIGN_PRIORITY_OWNER]
[SET_LEAD_PRIORITY: HIGH]
[SET_STATUS: VIP_FAST_TRACK]

Tier 2: Internal communication alert

[SEND_INTERNAL_ALERT_TO_SALES_CHANNEL]
[SEND_DIRECT_ALERT_TO_ASSIGNED_OWNER]
[SEND_DIRECT_ALERT_TO_SALES_MANAGER]

The internal alert should include enough context for the sales team to act immediately without opening multiple CRM tabs.

Notification payload

Lead name · Company name · Company website · Company LinkedIn URL · Contact LinkedIn URL · Job title · Target ICP segment · ICP confidence score · VIP score · Matched keywords · Reason for VIP classification · Lead source · Form intent · Recommended next action · Assigned owner · CRM record link

Example notification:

New VIP lead detected.

Lead:
Company:
Website:
ICP Segment:
ICP Confidence:
VIP Score:
Matched Keywords:
Reason:
Recommended Action:
Assigned Owner:
CRM Record:

24. Outreach sequence activation rules

The outreach sequence should only be activated when the required contact fields are available.

[IF: CONTACT_DATA_USABLE_FOR_OUTREACH?]

Required fields for sequence activation: email, first_name, company_name, target_icp_segment, vip_status.

If required outreach fields are missing:

[ASSIGN_STATUS: VIP_REVIEW_REQUIRED]
[CREATE_MANUAL_REVIEW_TASK]
[DO_NOT_ACTIVATE_SEQUENCE]

This prevents bad personalization, failed email sends, and poor sales handoff quality.

25. CRM update rules

The CRM should only be updated after all required lookup/fetch actions are complete.

[UPDATE_CONTACT_RECORD]
[UPDATE_COMPANY_RECORD]

Recommended contact fields to update

enrichment_status · classification_status · target_icp_segment · target_icp_confidence_score · target_icp_reason · matched_keywords · negative_keywords · vip_status · vip_score · vip_reason · vip_notified_at · manual_review_required · last_classified_at · classification_version

Recommended company fields to update

company_domain · company_website · company_linkedin_url · company_industry · company_size · company_description_clean · website_summary · company_profile_summary · company_keywords · target_icp_segment · target_icp_confidence_score · classification_status · last_enriched_at · last_classified_at

Fields that should not be overwritten automatically

record_owner · lifecycle_stage · original_source · existing_deal_association · closed_won_status · closed_lost_status · manual_sales_notes · manual_disqualification_reason

These fields should only be changed if the workflow has explicit permission from the routing rules.

26. Audit vault

Every classification decision should be saved into an audit vault or decision log.

[CREATE_AUDIT_LOG]

Audit log fields

lead_id · company_id · workflow_run_id · trigger_source · raw_input_snapshot · normalized_input_snapshot · enrichment_status · classification_status · target_icp_segment · target_icp_confidence_score · vip_status · vip_score · matched_keywords · negative_keywords · classification_reason · notification_sent · sequence_activated · manual_review_required · error_message · classification_version · created_at

Additional scraping audit fields

scrape_status · scrape_attempt_count · standard_fetch_used · rendered_browser_used · proxy_used · proxy_type · proxy_country · scrape_failure_reason · content_length_extracted · parsed_pages_count

The audit vault is important because it allows the team to understand why a lead was classified a certain way and whether the automation logic needs to be adjusted.

27. Edge cases

Missing email

If email is missing: continue enrichment if company data exists, do not activate the outreach sequence, assign status INCOMPLETE_CONTACT_DATA, and create a manual review task if ICP confidence is high.

Missing company website

If company website is missing: attempt to infer the company domain from the email. If the email uses a personal domain, mark the company website as unknown. Continue classification only if enough company data exists.

Personal email address

If the lead uses a personal email: do not rely on the email domain for company identification. Use company name, LinkedIn profile, and submitted form data. If the company cannot be verified, assign status INSUFFICIENT_DATA.

High ICP score but missing contact data

If the ICP score is high but contact data is incomplete: mark as PRIORITY_REVIEW, notify sales only if the company is highly valuable, and do not activate the outreach sequence until contact data is usable.

Existing owner

If the lead or company already has an owner: do not overwrite the owner automatically. Notify the existing owner. Only reassign if routing rules explicitly allow reassignment.

Existing active deal

If the company already has an active deal: do not create a new sales motion. Notify the deal owner and add classification details to the existing record.

Classification failed

If classification fails: assign status ICP_CLASSIFICATION_FAILED, save the error reason in the audit log, and create a manual review task.

Insufficient data

If there is not enough data for classification: assign status INSUFFICIENT_DATA, save the missing fields, and do not notify sales unless manually configured.

Website scraping failed

If website scraping fails: continue with available enrichment and company profile data, mark scrape_status as WEBSITE_PARSE_FAILED, do not block classification if enough other company data exists, and create a manual review task if strong ICP signals exist but website data is missing.

Enrichment lock stuck

If enrichment_status = ENRICHMENT_IN_PROGRESS for longer than the allowed TTL: mark the lock as stale, create an audit log, retry enrichment if the retry limit has not been reached, and create a manual review task if the retry limit is exceeded.

28. Final workflow logic

[TRIGGER: LEAD_RECEIVED_OR_UPDATED]

→ [CAPTURE_RAW_INBOUND_PAYLOAD]

→ [LOOKUP/FETCH_CONTACT_BY_EXACT_EMAIL]
→ [LOOKUP/FETCH_CONTACT_BY_EXACT_LINKEDIN_URL]
→ [LOOKUP/FETCH_COMPANY_BY_EXACT_DOMAIN]
→ [LOOKUP/FETCH_COMPANY_BY_EXACT_WEBSITE]
→ [LOOKUP/FETCH_COMPANY_BY_EXACT_LINKEDIN_URL]

→ [LOOKUP/FETCH_EXISTING_ENRICHMENT_STATUS]
→ [LOOKUP/FETCH_EXISTING_CLASSIFICATION_STATUS]
→ [LOOKUP/FETCH_EXISTING_OWNER]
→ [LOOKUP/FETCH_ACTIVE_DEALS]

→ [IF: ENRICHMENT_STATUS = ENRICHMENT_IN_PROGRESS]
   YES:
   → [CHECK_LOCK_AGE]
   → [IF: LOCK_IS_STALE]
        YES:
        → [SET_STATUS: ENRICHMENT_LOCK_STALE]
        → [CONTINUE]
        NO:
        → [CREATE_AUDIT_LOG: ENRICHMENT_ALREADY_IN_PROGRESS]
        → [END_OR_RETRY_LATER]

→ [NORMALIZE_CONTACT_AND_COMPANY_DATA]

→ [IF: REQUIRED_MINIMUM_DATA_MISSING?]
   YES:
   → [ASSIGN_STATUS: INSUFFICIENT_DATA]
   → [CREATE_MANUAL_REVIEW_TASK]
   → [CREATE_AUDIT_LOG]
   → [END]

→ [IF: ENRICHMENT_CACHE_VALID?]
   YES:
   → [FETCH_EXISTING_ENRICHMENT_DATA]
   → [SKIP_ENRICHMENT]

   NO:
   → [SET_STATUS: ENRICHMENT_IN_PROGRESS]
   → [ENRICH_CONTACT_AND_COMPANY]
   → [PARSE_COMPANY_WEB_PRESENCE]
   → [SCRAPE_ATTEMPT_1: STANDARD_HTTP_FETCH]
   → [IF: CONTENT_INVALID]
        → [SCRAPE_ATTEMPT_2: RENDERED_BROWSER_FETCH]
   → [IF: CONTENT_STILL_INVALID]
        → [SCRAPE_ATTEMPT_3: RENDERED_BROWSER_WITH_RESIDENTIAL_PROXY]
   → [SANITIZE_EXTRACTED_DATA]
   → [GENERATE_KEYWORD_DIRECTION]
   → [SET_STATUS: ENRICHMENT_COMPLETED]

→ [IF: CLASSIFICATION_CACHE_VALID?]
   YES:
   → [FETCH_EXISTING_CLASSIFICATION_DATA]
   → [SKIP_RECLASSIFICATION]

   NO:
   → [ICP_CLASSIFICATION]
   → [CALCULATE_ICP_CONFIDENCE_SCORE]

→ [IF: ICP_CLASSIFICATION_FAILED?]
   YES:
   → [ASSIGN_STATUS: ICP_CLASSIFICATION_FAILED]
   → [CREATE_MANUAL_REVIEW_TASK]
   → [CREATE_AUDIT_LOG]
   → [END]

→ [IF: ICP_CONFIDENCE_SCORE < 60]
   YES:
   → [ASSIGN_STATUS: ICP_NOT_MATCHED]
   → [UPDATE_CONTACT_RECORD]
   → [UPDATE_COMPANY_RECORD]
   → [CREATE_AUDIT_LOG]
   → [END]

→ [CHECK_VIP_ELIGIBILITY]
→ [CALCULATE_VIP_SCORE]

→ [IF: VIP_STATUS = VIP_FAST_TRACK]
   YES:
   → [ASSIGN_STATUS: VIP_FAST_TRACK]
   → [ASSIGN_PRIORITY_OWNER]
   → [CREATE_SALES_FOLLOW_UP_TASK]
   → [SEND_INTERNAL_ALERT_TO_SALES_CHANNEL]
   → [SEND_DIRECT_ALERT_TO_ASSIGNED_OWNER]
   → [SEND_DIRECT_ALERT_TO_SALES_MANAGER]
   → [IF: CONTACT_DATA_USABLE_FOR_OUTREACH?]
        YES:
        → [ACTIVATE_RELEVANT_OUTREACH_SEQUENCE]
        NO:
        → [CREATE_MANUAL_REVIEW_TASK]
   → [UPDATE_CONTACT_RECORD]
   → [UPDATE_COMPANY_RECORD]
   → [CREATE_AUDIT_LOG]
   → [END]

→ [IF: VIP_STATUS = PRIORITY_REVIEW]
   YES:
   → [ASSIGN_STATUS: PRIORITY_REVIEW]
   → [CREATE_MANUAL_REVIEW_TASK]
   → [UPDATE_CONTACT_RECORD]
   → [UPDATE_COMPANY_RECORD]
   → [CREATE_AUDIT_LOG]
   → [END]

→ [ASSIGN_STATUS: STANDARD_QUALIFIED]
→ [UPDATE_CONTACT_RECORD]
→ [UPDATE_COMPANY_RECORD]
→ [CREATE_AUDIT_LOG]
→ [END]

29. Final notes

This workflow should be treated as the company's lead intelligence and prioritization engine. The goal is to make sure every inbound or enriched lead is checked, cleaned, enriched, classified, scored, and routed correctly before sales action happens.

The most important production safeguards are:

• Exact lookup before normalization.
• Enrichment lock before external API calls.
• Cache check before paid enrichment.
• Rendered scraping before classification.
• Residential proxy only as fallback.
• Classification cooldown before reprocessing.
• VIP notification only when data supports the decision.
• Audit everything.

Blueprint spec sheet