Turn Website Visitors Into Routed, Qualified Leads

To turn website visitors into routed, qualified leads, treat the two kinds of visitor separately: the ones who never fill anything in become company rows (which company, which pages, from where), and the ones who ask for a demo are qualified against your ICP and routed while they are still on the page. On Cargo that is two cookbooks on the same site, visitor-identification and inbound-qualification, and they meet on the company’s domain.

A lead is a person who told you who they are. An anonymous visit is a company signal, never a person, so the honest go-to-market pipeline keeps the two apart and joins them on the account.

Deploy both #

On a site hosted on Cargo (see build and host your company website), inside its Cargo project:

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

cargo-ai cdk add cookbook/visitor-identification
cargo-ai cdk add cookbook/inbound-qualification
cargo-ai cdk plan
cargo-ai cdk deploy

Each add copies its code under infra/ and its procedure and site files under .claude/skills/, and your coding agent wires them into the website app: the consent gate and the tracker snippet for one, the contact page and the form’s tool uuid for the other. Both reach the app as env tokens in the same defineApp.

How it works, end to end #

anonymous visitor accepts tracking
  -> Snitcher resolves the visit to an organisation
  -> website_visiting_companies + website_visitor_sessions      (every 30 minutes at most)

visitor submits the demo form on /contact/
  -> public form API: origin, honeypot, time-trap, rate limit
  -> tool inbound_form: personal email refused -> company from the email domain -> ICP rules
  -> gtm_accounts + gtm_contacts -> one Slack post
  <- booking link if qualified, thank-you otherwise              (the page waits up to 30 seconds)

later, every 15 minutes, for contacts marked qualified (play shipped disabled)
  -> research agent: tier A, B, C or disqualified, and a three-sentence brief on the contact

The anonymous path is company-level by design. The site loads the tracker only after an explicit accept, and the two models hold the organisation (website, industry, first_seen, last_seen) and each session (referrer, views with the URL and time on page).

The form path is a Cargo tool with a public form, so there is no backend or form vendor. Each submission runs a workflow that looks up the company from the work email’s domain with LinkedIn enrichCompanyFromDomain, applies your ICP rules (a headcount band and a list of ISO country codes), upserts the account into gtm_accounts and the contact into gtm_contacts with lead_source website and an inbound_status of qualified, not_qualified or unknown_company, posts once to your Slack channel, and returns the answer the page shows.

Routing, as shipped, means two things: the qualified visitor gets your booking link on the page, and the team hears about every request in one locked Slack channel. Assigning an owner by territory or round robin before the post is the cookbook’s owner-routing variation, and writing to HubSpot, Salesforce or Attio instead of the shared models is crm-backed.

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. The rest land as unknown_company: still written and posted, without a qualification.

Where the two meet, and where they do not #

Both pipelines key on the company’s domain: the visiting company’s website, and gtm_accounts.website, which the form sets to the email domain. That is the join if you want to see, for an inbound lead, which pages their company read before they asked for a demo.

What the cookbooks do not do out of the box:

• The form workflow does not read the visitor models. Qualification uses the ICP rules only.
• No anonymous visit is routed to a rep or turned into a contact. An alert when a target account visits is a listed variation (a segment over the companies model joined to your target list, with an alert on new rows), not shipped code.
• Visits do not move a score unless you add the scoring-input variation with account-scoring.

What it needs #

• A website on Cargo hosting with an HTTPS canonical URL, and @cargo-ai/cdk 1.0.98 or later.
• The workspace’s default Snitcher and LinkedIn connections (both on Cargo’s credits), a Slack connection, and an Anthropic connection if you enable the research play.
• Your ICP written down, a booking link, a Slack channel id, and a privacy page with sections on the tracker and the contact form. Neither cookbook writes legal text.

What it costs #

List prices from each integration’s definition; read them live with cargo-ai connection integration get snitcher and cargo-ai connection integration get linkedin. Plays and tools also bill orchestration steps, 1 credit per 100 steps. Visitor spend follows traffic with no built-in cap; form spend is bounded by the origin allow-list and a rate limit of ten submissions a minute per address.

What it will not do #

• Name an anonymous visitor. No identify call, no email capture, no person inferred from an IP address.
• Enrich the person who filled the form. The company is enriched; the person already said who they are.
• Load the tracker before consent, or set the form’s cargo_anon_id cookie before a submission.
• Send anything. Neither cookbook emails a visitor or a lead. Marketing email needs the marketing_consent box ticked, and the follow-up is yours.

Deploy them from the visitor-identification and inbound-qualification cookbooks. Each half in depth: identify which companies visit your website and qualify and route demo requests in seconds.