Cut Inbound Request Rot by 60 Percent Without More Staff

You don’t have a lead problem. You have a “someone saw it” problem, where inbound requests land in five places, get skimmed once, and then rot until the customer follows up with a second email that sounds like a breakup text. That’s not pipeline. That’s latency dressed as effort. This playbook is about building an intake-to-action system for product inquiries and partner requests that actually closes the gap between “message received” and “work started,” without turning your team into human routers. The outcome is concrete: every inbound request gets captured, classified, routed, acknowledged with the right context, and tracked to completion in one operating loop. We’re going to use four tools with non-overlapping jobs: Airtable as the source of truth for requests, status, ownership, and SLAs. n8n as the automation spine that pulls requests in, pushes assignments out, and enforces timing. Perplexity as the fast research layer that turns vague inbound names and domains into usable company context. HubSpot CRM as the system of record for accounts, contacts, and deal linkage once a request is qualified. The workflow is intentionally opinionated: stop asking humans to decide what a request is before you’ve given them a structured card to react to. We’ll build a single intake endpoint (form, inbox, or webhook), normalize the payload in n8n, enrich it with Perplexity (industry, size signals, key product lines, recent news), then write a complete request record to Airtable with an owner and due-by timestamp. Then the system forces the next move: create or update the matching HubSpot contact/company, associate the request to the right pipeline stage, and send the requester a confirmation that reflects what you understood, not a generic autoresponder. If you can’t point to one table row and one CRM object for every inbound, you don’t have visibility. You have anecdotes.

It’s 9:12 a.m. Maya, the growth lead, opens Slack to six pings: “Did anyone see the partnership email from Orion?” “A lead just DM’d the CEO on LinkedIn.” “Support forwarded a ‘pricing question’ thread.” She already knows what happens next. Someone “takes it,” nobody logs it, and three days later the prospect replies with: “Just checking in…” The breakup-text energy. So the new system is live. One intake endpoint: a shared inbox piped into n8n. Every inbound becomes a payload. n8n parses subject/body, grabs the sender domain, then calls Perplexity: what is Orion, what do they sell, any recent funding, who do they compete with. That enrichment isn’t for vanity. It sets the Airtable fields that drive routing: request type, ICP fit, urgency, recommended owner, SLA clock. Airtable gets one clean row. Owner assigned. Due-by timestamp. Status starts at New. n8n then hits HubSpot: find or create Company by domain, Contact by email, associate the request, open a deal if it’s sales-qualified. Then an acknowledgment email goes out that mirrors reality: “Looks like you’re asking about API access + reseller terms. We’ll respond by tomorrow 3 p.m.” Friction shows up immediately. The first week, Maya notices duplicates. Same company. Three Airtable rows. Two HubSpot companies. Why? An incorrect implementation: they matched companies on “company name” from email signatures instead of domain. “Orion,” “Orion Tech,” “Orion Technologies Inc.” All different. n8n happily created objects. The system looked busy. The pipeline got noisier. Then there’s the messier part: Perplexity sometimes returns a parent brand when the email domain is a subsidiary. Who owns routing then. Sales? Partnerships? Support? There’s no clean answer. They fix it by enforcing domain as the primary key, adding a manual review queue when confidence is low, and making the SLA pause automatically when a human flags “ambiguous entity.” Not perfect. Just accountable. Every inbound has a row. Every row has a next move. Or it’s visibly stuck.

Here’s the part nobody tells you when they copy a “single intake + automation + enrichment” workflow: it doesn’t fail because of tooling. It fails because you accidentally create a new bureaucracy and call it operational excellence. Once the basics work, volume is the next enemy. The system will happily ingest 200 requests a week, enrich them, assign owners, open deals, and send polished acknowledgments. And that’s the trap: it looks responsive while quietly turning your team into SLA janitors. If you don’t have a firm definition of what “done” means per request type, you’ll get a graveyard of “Waiting on customer” and “In review” statuses that technically stop the clock but don’t move revenue or partnerships forward. Also: Perplexity enrichment is not free. Not in dollars, in decisions. Every enrichment field you add becomes a routing lever, and routing levers become political. “Why did Partnerships get this?” “Why did Sales take that?” You’ll discover you don’t have an intake problem, you have an org design problem. The workflow just surfaces it. The scalable version isn’t adding more automations. It’s narrowing the number of paths. Three request types max to start. One default owner per type. One escalation rule. Everything else goes into a triage queue with an explicit capacity limit. If triage hits 30 items, you don’t “work harder.” You change the intake copy, add gating questions, or push low-signal requests to self-serve. And watch your keys. Domain matching solves duplicates until you meet consultancies, Gmail senders, and partner ecosystems where the domain isn’t the economic buyer. Then your “source of truth” turns into a source of arguments. The fix is pragmatic: allow multiple identities per request, store confidence, and treat association as a reversible decision, not a one-way create call into HubSpot. This system is strong when it’s honest. The best outcome isn’t automation. It’s making stuck work visible fast enough that the business has to choose what it will ignore.