Routing Inbound Demo Requests with Default + Slack

Inbound demo request routing sounds simple until you are doing it: the form submits, a lead record is created, and then six different systems compete to decide what happens next. Marketing automation fires a nurture sequence. Sales ops waits for CRM assignment. The AE checks Slack 40 minutes later. The prospect has already moved on.

This playbook builds a routing system where a qualified demo request reaches the right AE’s Slack DM within 90 seconds of form submission, with full context, ICP score, and a Calendly link. Unqualified requests get a routing decision too — a nurture sequence or a polite decline, not a black hole. The stack: Default for form capture and routing logic, Slack for real-time AE notification, HubSpot as CRM of record, and Linear for tracking routing system health.

Setup: Prerequisites and Stack Configuration

• Default account: Growth plan or above ($500/month). The ICP scoring logic and multi-path routing require Default’s conditional branching, which is a paid feature.
• HubSpot: Default has a native HubSpot integration. You will need a HubSpot API key and the contact/company objects accessible. CRM of record does not have to be HubSpot — Default also integrates with Salesforce — but this playbook uses HubSpot examples.
• Slack workspace: Default’s Slack integration requires a Slack app installation with the chat:write and channels:read scopes. Your Slack admin will need to approve the installation.
• Linear workspace: Optional but recommended. Default can create Linear issues via webhook; Linear is used here to track routing failures, unmatched leads, and system latency.

Before building the routing flow, define your AE pods. A pod is a named group of AEs assigned to a territory or segment. Typical segmentation: pod-enterprise (ACV >$50K), pod-midmarket (ACV $10K–50K), pod-smb (ACV <$10K), pod-emea, pod-apac. Define these before touching Default — the pod structure drives your Slack channel naming and routing logic.

Step 1: Build the Default Form and ICP Scoring Logic

In Default, create a new flow. Start with a Form trigger node. Configure the form fields to capture: first name, last name, work email, company name, company size (dropdown: 1–10, 11–50, 51–200, 201–1000, 1001+), and the free-text “What are you trying to solve?” field. Do not ask for phone number on the initial form — it reduces conversion rates by 20–35% with minimal additional qualification signal at this stage.

After the Form trigger, add an Enrich node. Connect to your enrichment provider (Default natively integrates with Clearbit/HubSpot Enrichment, Apollo via HTTP node, and Bombora for intent). At minimum, enrich: company domain, company headcount (actual, not self-reported), industry, tech stack (specifically: are they a Salesforce shop? HubSpot? Neither?), funding stage, and Bombora intent score if available.

Next, add a Score node. Default’s Score node lets you define a weighted scoring formula. Here is a working ICP scoring configuration for a typical B2B SaaS company selling to revenue teams:

// Default ICP Score configuration (JSON shape matching Default's flow definition)
{
  "node_type": "score",
  "node_id": "icp_score",
  "score_field": "icp_score",
  "max_score": 100,
  "rules": [
    {
      "field": "company.headcount",
      "condition": "between",
      "values": [50, 500],
      "points": 25,
      "label": "Target headcount range"
    },
    {
      "field": "company.headcount",
      "condition": "between",
      "values": [501, 2000],
      "points": 15,
      "label": "Large company - longer cycle"
    },
    {
      "field": "company.industry",
      "condition": "in",
      "values": ["B2B SaaS", "Financial Services", "Professional Services"],
      "points": 20,
      "label": "Target industry"
    },
    {
      "field": "company.technologies",
      "condition": "contains_any",
      "values": ["Salesforce", "HubSpot"],
      "points": 15,
      "label": "CRM signal - integration fit"
    },
    {
      "field": "contact.seniority",
      "condition": "in",
      "values": ["VP", "Director", "C-Suite", "Head of"],
      "points": 20,
      "label": "Decision-maker seniority"
    },
    {
      "field": "intent.bombora_score",
      "condition": "gte",
      "values": [70],
      "points": 20,
      "label": "Active intent signal"
    }
  ],
  "thresholds": {
    "hot": 70,
    "warm": 45,
    "cold": 0
  }
}

Calibrate the thresholds against your historical win data. If 60% of your closed-won deals came from leads scoring 65+, set your “hot” threshold at 65, not 70. Default’s analytics panel shows score distribution across past submissions — use it to set thresholds on real data, not intuition.

Step 2: Route to AE Pod via Slack

After the Score node, add a Branch node. Configure three branches based on icp_score: Hot (≥70), Warm (45–69), and Cold (<45).

Hot branch: Route directly to AE pod Slack channel with high urgency. Add a Route node to determine which pod. Pod assignment logic:

// Default Route node configuration for pod assignment
{
  "node_type": "route",
  "node_id": "pod_assignment",
  "routing_rules": [
    {
      "condition": "company.headcount >= 1000",
      "output": "pod-enterprise",
      "slack_channel": "#routing-enterprise"
    },
    {
      "condition": "company.region == 'EMEA'",
      "output": "pod-emea",
      "slack_channel": "#routing-emea"
    },
    {
      "condition": "company.headcount >= 201 AND company.headcount < 1000",
      "output": "pod-midmarket",
      "slack_channel": "#routing-midmarket"
    },
    {
      "condition": "default",
      "output": "pod-smb",
      "slack_channel": "#routing-smb"
    }
  ]
}

Slack channel naming convention: Use #routing-{pod} for pod-level routing channels (e.g., #routing-enterprise, #routing-midmarket). Use #routing-alerts for system-level issues (routing failures, unmatched leads, latency spikes). Do not use #leads or generic channel names — they become noisy fast and AEs stop monitoring them.

In the Slack Message node, configure the message template for the routing channel:

// Default Slack Message node template
{
  "channel": "{{pod_assignment.slack_channel}}",
  "text": "*New HOT inbound 🔥* — ICP Score: {{icp_score}}/100",
  "blocks": [
    {
      "type": "header",
      "text": "New HOT Demo Request — {{icp_score}}/100"
    },
    {
      "type": "section",
      "fields": [
        { "label": "Contact", "value": "{{contact.first_name}} {{contact.last_name}}, {{contact.title}}" },
        { "label": "Company", "value": "{{company.name}} ({{company.headcount}} employees)" },
        { "label": "Industry", "value": "{{company.industry}}" },
        { "label": "Tech Stack", "value": "{{company.technologies}}" },
        { "label": "What they said", "value": "{{form.problem_statement}}" },
        { "label": "Funding", "value": "{{company.funding_stage}}" }
      ]
    },
    {
      "type": "actions",
      "elements": [
        { "type": "button", "text": "Claim this lead", "action_id": "claim_lead", "value": "{{lead.id}}" },
        { "type": "button", "text": "View in HubSpot", "url": "{{hubspot.contact_url}}" }
      ]
    }
  ]
}

The "Claim this lead" button triggers a Default webhook that records which AE claimed the lead and timestamps the claim. This gives you AE response time data in Linear without manual tracking.

Round-robin fallback: If no AE claims the lead within 10 minutes (configure Default's wait node with a 10-minute timeout), fire a second Slack message to the pod channel tagging the pod manager: "@{pod_manager} — unclaimed HOT lead, 10 min elapsed." After 20 minutes, escalate to #routing-alerts and create a Linear issue automatically.

Step 3: Instrument with Linear

Add a Linear integration node at two points in the flow: on successful routing (to track lead volume by pod) and on routing failure or timeout (to create a bug/task for the RevOps team).

// Default HTTP node to create Linear issue on routing timeout
// Method: POST
// URL: https://api.linear.app/graphql
// Headers: { "Authorization": "Bearer {{env.LINEAR_API_KEY}}", "Content-Type": "application/json" }
// Body:
{
  "query": "mutation CreateIssue($input: IssueCreateInput!) { issueCreate(input: $input) { success issue { id title } } }",
  "variables": {
    "input": {
      "teamId": "{{env.LINEAR_REVOPS_TEAM_ID}}",
      "title": "Unclaimed HOT lead: {{contact.first_name}} {{contact.last_name}} @ {{company.name}}",
      "description": "ICP Score: {{icp_score}}\nPod: {{pod_assignment.output}}\nSubmitted: {{flow.trigger_time}}\nHubSpot: {{hubspot.contact_url}}",
      "priority": 1,
      "labelIds": ["{{env.LINEAR_ROUTING_LABEL_ID}}"]
    }
  }
}

After two weeks of running, pull the Linear issue count by label to see your routing failure rate. A healthy system should have fewer than 5% of hot leads generating a Linear escalation. Above 10% means either your pod coverage has gaps (AEs offline during certain hours) or your hot threshold is set too high and generating too much volume for AEs to respond to.

What Happens to MQLs That Aren't ICP-Fit

This is the edge case most routing playbooks skip: what do you do with a lead who converted on the demo form but scored below your ICP threshold? A 38/100 ICP score from a 12-person startup in a non-target vertical is a real person who wants to talk to you. Routing them to an AE wastes the AE's time and creates a bad prospect experience when the AE is clearly not interested.

The Warm branch (<70, ≥45) gets a different treatment: they receive an automated email offering a self-serve demo recording (Loom or Navattic interactive demo) plus a calendar link to book with an SDR, not an AE. The SDR does a 20-minute discovery call. If discovery reveals ICP fit that the enrichment data missed (enrichment is imperfect), the SDR can re-route to an AE manually via HubSpot. This catches the roughly 15–20% of leads that score as Warm on firmographics but turn out to be strong buyers in discovery.

The Cold branch (<45) is honest: they get an automated confirmation email pointing to your documentation, pricing page, and a self-serve free trial if you have one. No sales follow-up. This is not rude — it is respectful of everyone's time. The alternative (routing all Cold leads to SDR sequences) generates noise, low conversion, and SDR burnout.

Troubleshooting

• Enrichment returning nulls for company data: Work email domains that are free email providers (Gmail, Yahoo) will not resolve to company data. Add a validation step before enrichment that checks the email domain against a free-email-provider blocklist. Default has a built-in email validation node. Leads with personal emails get routed to the Cold branch regardless of other signals.
• Slack messages not appearing in pod channel: Check that the Default Slack app has been added to the specific pod channels, not just the workspace. Slack's channel membership for apps is separate from workspace installation.
• ICP scores skewing uniformly low: Your enrichment is returning sparse data. Check the coverage rate on your enrichment node — if more than 30% of contacts are returning null on key scoring fields (headcount, industry, tech stack), the scoring model is running on partial data and the scores are meaningless. Fix the enrichment source before tuning thresholds.
• AEs not responding to Slack messages: The routing channel is too noisy or the message format is not scannable in 5 seconds. Simplify the Slack message to three fields: company name, headcount, and ICP score. AEs will click through to HubSpot for context; the Slack message just needs to trigger the reflex to claim the lead.

What This Doesn't Solve

Lead deduplication. Default will create a new flow execution for every form submission, including from prospects who have submitted before or who are already active opportunities in your CRM. Before routing, add a HubSpot lookup node to check for an existing contact record by email and an existing open deal associated with that contact. If an open deal exists, route to the deal owner rather than the pod channel — skipping the ICP scoring entirely.

Multi-stakeholder buying groups. The routing system handles one contact at a time. When two people from the same company submit the demo form within 48 hours, Default treats them as independent leads. Build a company-level deduplication step that checks the HubSpot company object for recent form submissions from the same domain before creating a second routing event.

Related reading: See the Default vendor profile for a full breakdown of pricing, native integrations, and how it compares to Chili Piper and Calendly for inbound routing. For enrichment setup upstream of the routing flow, see the Clay waterfall enrichment playbook. The Default vs. Chili Piper comparison covers when each tool wins on inbound scheduling and routing complexity.