Qualify and Route Demo Requests in Seconds

To qualify and route demo requests in seconds, make the demo form itself the qualification step: each submission identifies the company from the work email’s domain, checks it against your ICP rules, lands the account and the contact, posts once to your sales channel, and answers on the page with your booking link if they fit and a thank-you if they do not. There is no queue for a lead to cool in, nights and weekends included, because no person sits between the submit button and the answer.

The inbound-qualification cookbook declares this as one Cargo tool with a public form, so there is no backend to run and no form vendor. This page covers the path a submission takes, what it costs, and where it stops.

Deploy it #

The form sits on a site hosted on Cargo, usually from build and host your company website. Inside that project:

npm install -g @cargo-ai/cli
cargo-ai login --email you@company.com

cargo-ai cdk add cookbook/inbound-qualification
npm install @cargo-ai/form-sdk --prefix infra/website-building/apps/website
cargo-ai cdk plan
cargo-ai cdk deploy

Four values are yours to set before the deploy: the ICP rules (icpMinEmployees, icpMaxEmployees, icpCountries), the bookingUrl, the Slack channel id, and publicForm.allowedOrigins, your site’s canonical origin exactly, with no trailing slash. The website app receives the tool’s uuid as NEXT_PUBLIC_CARGO_FORM.

How a submission is handled #

visitor submits /contact/ (headless @cargo-ai/form-sdk, your own markup)
  -> public form API: origin, honeypot, time-trap, rate limit
  -> tool inbound_form:
       personal email domain?   -> "work_email_required", nothing paid, nothing written
       LinkedIn enrichCompanyFromDomain on the email domain
       ICP rules: employee_count within the band, hq_country in the list
       upsert gtm_accounts (matched on website) and gtm_contacts (matched on email)
       one Slack post to the locked channel
  <- "qualified" + booking link, or "not_qualified"

Checked in order, each one refusing the request: an origin not in allowedOrigins gets a 403; a filled honeypot field is dropped; a submission sooner than minFillMillis (3,000 ms in the example) after the SDK loaded is refused; more than ten submissions a minute from one address are rate-limited; a CAPTCHA (Turnstile or hCaptcha) applies only if you add it; and the workflow refuses a personal email before any paid call.

The page waits up to 30 seconds. The form submits in async mode and the SDK polls the run, with pollTimeoutMs: 30_000. A run is mostly the company lookup. If it runs past the timeout the visitor gets the thank-you, and the run still finishes: the account, the contact and the Slack post land late, never lost.

Rules, not a model call, on the submission path. A headcount band and a list of ISO country codes are free, explainable and give the same answer twice. Swapping them for an agent that reads your ICP is the agent-qualification variation, at the price of a model call per submission and a less predictable answer.

Cargo platform data, 90 days to Oct 16 2026: company enrichment, the job the form runs on every work email, returned a company in 91.6% of 2.45 million runs across 210 workspaces. A domain with no company match is written and posted as unknown_company, without a qualification.

What lands where #

A second submission from the same person updates their row instead of adding one.

Deep research, after the answer. A separate play, research_qualified_leads, ships disabled. Once enabled it runs every 15 minutes for contacts marked qualified and not yet researched: an agent reads your ICP and tiering rubric from the workspace context, uses at most four web searches, and writes inbound_tier (A, B, C or disqualified), inbound_brief, inbound_rationale and inbound_researched_at onto the contact, with a short note to the same channel. It never runs inside the form, so the visitor never waits on it.

Routing beyond one channel #

As shipped, routing is the booking link for a fit and one locked Slack channel for the team. Two variations take it further: owner-routing assigns owner_id by territory or round robin before the post and mentions the owner, and crm-backed writes to HubSpot, Salesforce or Attio instead of the shared models. For territory, round-robin and capacity rules as a product feature, see routing, and for why assignment often moves out of the CRM, alternatives to CRM-native lead routing.

What it costs #

Read the live price with cargo-ai connection integration get linkedin. The tool also bills orchestration steps (1 credit per 100) and the models storage upserts (1 credit per 1,000). The origin allow-list keeps other sites from spending your credits.

What it will not do #

• Enrich the person. The company is looked up from the domain; no person lookup, personal email or phone search runs on a submitter.
• Accept a personal email unless you choose the accept-personal-email variation, which leaves those contacts without an account.
• Book the meeting. qualified means the company fits and was shown the link; whether they booked lives in your scheduling tool.
• Send marketing email without the consent box ticked. A demo request alone is not consent to a newsletter.
• Set a cookie before a submit. The SDK sets its cargo_anon_id cookie only when a visitor submits, and not under Global Privacy Control or Do Not Track.

Deploy it from the inbound-qualification cookbook. To score a list rather than a form, see how to qualify a list of leads against your ICP; to add the companies that read the site without filling anything in, turn website visitors into routed, qualified leads.