Shared Inbox Lead Router: 3 Gates Before Any Reply

By Lazar Milicevic · Published August 9, 2026 · 11 min read

Most small teams do not lose leads because they lack a CRM. They lose them because a real inquiry arrives between newsletters, support tickets, invoices, vendor outreach, and an inbox nobody clearly owns.

The fix is not an AI agent that sends replies on its own. It is a three-gate workflow that extracts facts, routes the message with visible rules, and puts a human-approved action in front of the right person.

Gate 1: Capture the right emails and preserve the original record

A safe shared-inbox router starts with a narrow Gmail intake, not access to every message in the mailbox. Label only the inbound emails you want inspected, save the original message data, and clean the newest email content before an AI model sees it.

The Gmail API is suitable for this because, as Google puts it, “[t]he Gmail API is a RESTful API that can be used to access Gmail mailboxes and send mail.” But the ability to access a mailbox does not mean your workflow should inspect everything in it on day one.

Start with a Gmail filter that applies a label such as ai-router-review to new messages sent to your sales or shared inbox.

A practical first filter:

to:(sales@yourcompany.com OR hello@yourcompany.com)
-newer_than:30d
-from:(yourcompany.com)
-category:promotions

Then exclude known automated senders where possible:

from:(noreply OR no-reply OR notifications OR alerts)

Do not depend on this query alone. Keep a configurable allowlist and blocklist in your workflow database so you can change routing behavior without editing Gmail filters.

When a labeled email arrives, save the raw intake record before doing anything else.

{
  "message_id": "18f4d1f0a8c2",
  "thread_id": "18f4d1e9b9d7",
  "received_at": "2026-08-09T14:22:11Z",
  "from_name": "Maya Chen",
  "from_email": "maya@northstarco.com",
  "subject": "Need help connecting Gmail to HubSpot",
  "raw_body": "Hi team, ...",
  "attachment_metadata": [
    {
      "filename": "requirements.pdf",
      "mime_type": "application/pdf",
      "size_bytes": 248119
    }
  ],
  "workflow_status": "received"
}

That original record matters for three reasons:

1. You can investigate a wrong classification without guessing what the model saw.
2. You can rerun an improved extraction prompt against historical messages.
3. You have an audit trail when someone asks why a message was routed, assigned, or archived.

Clean the email before sending it to the model

The newest human-written content is usually a small fraction of an email thread. Signatures, confidentiality notices, social media links, and quoted replies create noise. Worse, a model can mistake an old request in a thread for the sender’s current request.

Strip these before extraction:

• HTML tags and tracking pixels
• Repeated legal footers
• Previous quoted messages beginning with patterns such as On ... wrote:
• Email signatures after delimiters such as --
• Embedded forwarded-message headers
• URLs that do not affect the routing decision

Here is a simple Python baseline. It will not handle every mail client, but it is better than sending raw threads unchanged.

import re
from bs4 import BeautifulSoup

def clean_email_body(html_or_text: str) -> str:
    text = BeautifulSoup(html_or_text, "html.parser").get_text("\n")

    # Remove common reply-chain markers.
    text = re.split(r"\nOn .+ wrote:\n", text, maxsplit=1)[0]
    text = re.split(r"\nFrom:.+\nSent:.+\nTo:.+\nSubject:.+", text, maxsplit=1)[0]

    # Remove signature block.
    text = re.split(r"\n--\s*\n", text, maxsplit=1)[0]

    # Collapse empty lines.
    text = re.sub(r"\n{3,}", "\n\n", text).strip()

    return text[:12000]

The 12000 character limit is deliberate. A shared inbox router does not need a 45-message thread to decide whether an email belongs in sales, support, billing, or manual review. If an email is longer than the limit, preserve the raw body in storage and show the complete original to the reviewer.

For Gmail implementation details, use Google’s official Gmail API documentation rather than relying on old OAuth tutorials. Email access scopes are sensitive. Request the minimum scopes your system needs, and review access whenever a team member leaves.

Gate 2: Extract structured facts instead of asking AI to “understand the lead”

The model’s first job is to convert an unstructured email into a fixed record, not to write a persuasive reply. Structured extraction makes the next step testable: you can inspect fields, compare outputs, and identify exactly what information is missing.

This distinction prevents a common failure. A polished AI summary can sound confident even when the sender never stated a budget, company name, timeline, or actual problem.

Use a schema that matches the decisions your team needs to make. For a service business or small SaaS team, this is enough:

contact:
  name: string | null
  email: string
  phone: string | null

company:
  name: string | null
  website: string | null
  location_or_market: string | null

request:
  requested_service: string | null
  summary: string
  stated_urgency: low | medium | high | unknown
  budget_signal: string | null
  timeline: string | null

missing_information:
  - string

evidence:
  - field: string
    source_text: string

The evidence field is worth keeping. It forces the system to retain the sentence that supports an extracted fact rather than quietly inventing one.

For this email:

Subject: CRM and inbox automation

Hi,

I run operations at Northstar Co. We use Gmail and HubSpot, but new inquiries
sit in our shared inbox too long. We want to fix this before our September
campaign. Can you send a rough implementation plan?

Thanks,
Maya

The extraction result should look boring:

{
  "contact": {
    "name": "Maya",
    "email": "maya@northstarco.com",
    "phone": null
  },
  "company": {
    "name": "Northstar Co.",
    "website": null,
    "location_or_market": null
  },
  "request": {
    "requested_service": "Gmail and HubSpot shared inbox automation",
    "summary": "Northstar Co. wants to reduce delays in handling new shared-inbox inquiries before a September campaign.",
    "stated_urgency": "medium",
    "budget_signal": null,
    "timeline": "before September campaign"
  },
  "missing_information": [
    "Current inquiry volume",
    "Budget range",
    "Whether HubSpot is the system of record"
  ],
  "evidence": [
    {
      "field": "timeline",
      "source_text": "We want to fix this before our September campaign."
    }
  ]
}

Notice what it does not do: declare this a high-value lead, invent a budget, or decide that the company is ready to buy.

Use extraction prompts that prohibit guessing

Your system instruction should be explicit about null values and evidence:

Extract facts from the newest email only.

Return valid JSON matching the supplied schema.
Do not infer facts that are not stated.
Use null when a field is absent.
Set urgency to "unknown" unless the sender provides a deadline,
time-sensitive problem, or explicit urgency.
For every non-null business field, add a short evidence quote from the email.
Do not draft a reply.

This gives you a useful operational record even when the email is vague. “Can you help us with automation?” is not a failure case. It is a record with requested_service: "automation" and a missing_information list that tells the reviewer what to ask next.

Gate 3: Classify with confidence, then let deterministic rules override the model

AI should classify ambiguous language, while deterministic rules should handle facts your business already knows. The safest routing design uses mutually exclusive categories, a confidence threshold, and rule-based overrides that are visible outside the prompt.

Keep the initial classification list short:

Require two additional fields:

{
  "classification": "possible_lead",
  "confidence": 0.81,
  "reason": "The sender describes a relevant automation problem and timeline but provides no scope, budget, or volume."
}

A confidence score is not an objective truth metric. It is a control for deciding whether the workflow can proceed automatically.

A practical policy:

routing_policy:
  auto_route_threshold: 0.85
  manual_review_threshold: 0.60

  below_0_60:
    queue: uncertain
    action: no_downstream_action

  from_0_60_to_0_84:
    queue: human_review
    action: prepare_recommendation_only

  from_0_85_to_1_00:
    queue: route_by_classification
    action: create_draft_or_record_only

Even above 0.85, do not give the model permission to send an external email. High confidence may justify creating a CRM record or assigning an owner. It does not replace judgment about pricing, promises, legal language, product availability, or tone.

Add overrides outside the AI prompt

Your business rules should run after extraction and before the final queue assignment.

def apply_routing_overrides(record, crm_match):
    subject = record["subject"].lower()
    sender_domain = record["from_email"].split("@")[-1]

    if crm_match and crm_match["account_status"] == "active_customer":
        return "customer_support", "existing customer match"

    if "invoice" in subject or record.get("invoice_number"):
        return "billing_or_account", "invoice signal"

    if sender_domain in {"stripe.com", "hubspot.com", "google.com"}:
        return "internal_or_automated", "known system sender"

    if record["classification"] == "vendor_or_partnership":
        return "vendor_or_partnership", "model classification"

    return record["classification"], "no override"

This is the division of labor that works:

• AI handles wording such as “We are evaluating options for a new intake process.”
• Rules handle facts such as “This sender belongs to an active customer account.”
• Humans handle exceptions, commitments, and anything externally visible.

The router can also look up the sender in your CRM. Send only the minimum context required for a useful decision: account owner, account status, open deal status, and perhaps the last support-ticket date. Do not dump full CRM notes, deal history, payment data, or internal commentary into the model context.

The approval card is where the workflow becomes useful

The approval card should let a person make the next correct decision in under one minute. If reviewers need to open Gmail, the CRM, Slack, and a spreadsheet before acting, you built another notification system rather than a lead router.

I use Telegram for this pattern in small teams because it is fast, mobile-friendly, and supports buttons. Slack, Microsoft Teams, or an internal dashboard can use the same structure.

A good approval card fits on one screen:

POSSIBLE LEAD · 0.81 confidence

From: Maya <maya@northstarco.com>
Company: Northstar Co.
Owner: Unassigned
Timeline: Before September campaign

Request:
Connect Gmail and HubSpot so shared-inbox inquiries do not sit too long.

Missing:
• Inquiry volume
• Budget range
• Current CRM ownership

Recommended action:
Send one clarifying question and create a CRM lead draft.

Original email:
"Hi, I run operations at Northstar Co..."

Then show three actions:

[Approve]  [Edit]  [Reject]

The meanings must be unambiguous:

• Approve performs the proposed downstream action exactly as displayed.
• Edit opens the draft or record fields for changes before any external action.
• Reject stops the action and requires a rejection reason from a short list.

For example:

rejection_reasons:
  - wrong_classification
  - duplicate_lead
  - insufficient_information
  - spam_or_irrelevant
  - handled_manually
  - other

A rejection reason becomes training data for your workflow, even if you never fine-tune a model. After 50 to 100 reviewed messages, you can inspect patterns:

• Are partnership requests landing in possible leads?
• Are existing customers being treated as prospects?
• Are invoice subjects too broad a billing rule?
• Are reviewers rejecting drafts because they are too long?

This is how a working system improves: through recorded operational decisions, not prompt tweaking in isolation.

Build for retries, duplicates, and human mistakes from day one

Shared-inbox automation needs idempotency and audit logs because Gmail events, webhook calls, and button clicks can be delivered more than once. A router that creates duplicate leads or sends a draft twice will lose trust faster than a manual inbox ever did.

Use the Gmail message_id as your first idempotency key. Store every state transition.

CREATE TABLE inbox_router_events (
  id UUID PRIMARY KEY,
  gmail_message_id TEXT NOT NULL,
  thread_id TEXT NOT NULL,
  event_type TEXT NOT NULL,
  actor_type TEXT NOT NULL,
  actor_id TEXT,
  payload JSONB NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  UNIQUE (gmail_message_id, event_type)
);

Before creating a CRM lead, check both:

1. Has this Gmail message already created a lead?
2. Does the sender email already exist as an open lead, contact, or account?

Your action handler should also validate the approval state server-side. Never trust a button payload by itself.

def approve_action(message_id: str, reviewer_id: str):
    record = load_router_record(message_id)

    if record.status != "awaiting_approval":
        raise ValueError("This message was already handled.")

    if record.confidence < 0.60:
        raise ValueError("Low-confidence messages require manual routing.")

    with database_transaction():
        mark_approved(record.id, reviewer_id)
        execute_proposed_action(record)
        write_event(record.id, "approved", "human", reviewer_id)

The order matters. Mark the approval and create the downstream record inside a transaction where possible. If the CRM API fails after approval, set the record to action_failed and notify the reviewer. Do not silently mark it complete.

Also measure the system with operational numbers that matter:

Do not claim ROI from a router before you have baseline data. Pull 30 days of shared-inbox activity first: number of inbound messages, time to first response, missed assignments, and duplicate CRM entries. Then compare the same metrics after the workflow has been running long enough to include normal business cycles.

Why bizflowai.io helps with this

bizflowai.io helps small businesses implement this kind of controlled inbox automation: Gmail intake, structured extraction, CRM lookups, support and billing routing, and human approval cards before external actions happen. The work is built around the client’s actual inbox rules and existing tools, with logs and review states included so the system can be inspected when a classification is wrong. See the implementation approach at bizflowai.io.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.