Organization, project and product

LeadHunter has three levels of container: Organization, Project and Product. Everything else hangs off the project.

Organization (Acme Agency)
 ├── Project "Bike shops"      ← owns accounts, campaigns, stats…
 │    ├── Product "FleetMate"
 │    └── Product "FleetMate Pro"
 └── Project "Pet stores"
      └── Product "PetDesk"

Organization — the roof over your projects

An Organization groups several projects that belong to the same business or team — for example an agency Acme Agency running a Bike shops project and a Pet stores project. It carries a name, a slug and an optional description, plus its own member list with the roles owner, admin and member.

The organization does not own accounts, campaigns or any other operational data. It is there to:

keep related projects together in the project switcher and on the Projects page;
give you an Organization overview (a tab of Insights, also in the project switcher’s footer) — one outreach funnel added up across that organization’s projects you belong to;
decide who can create new projects in it (owners and admins) and pre-fill each new project’s team with the organization’s members.

An organization can’t be deleted while it still has projects. See Team, projects and organizations for roles and access.

Project — your data boundary

A Project is the unit that owns data. Each project is fully isolated from every other project, including its siblings in the same organization. It carries:

Bucket	Holds
Identity	`name`, `slug` (auto-generated from name, unique site-wide), `description`, `is_active`, the organization it belongs to
Members	Team users and their roles (`owner`, `admin`, `member`)
Owned data	Accounts, Products, Campaigns, Conversations, Research records, Custom-field definitions, Saved views, Channels, Webhooks, Client Pulse, Marketing actions, Campaign and channel expenses, usage and costs, funnel and insights
Provenance	`created_at`, `updated_at`

One user can belong to many projects. The active project is selected in the project switcher in the top bar; everything you see on every page — accounts, campaigns, statistics, costs — is scoped to that selection. The selection persists across sessions.

Project or product?

A project can hold several products, so you have two ways to split your work:

Situation	Use
A separate line of business with its own accounts and its own funnel (a different market, a different client of your agency)	A separate project
Different things you sell to the same pool of accounts	A separate product inside the same project

Rule of thumb: if the two efforts should share one account database (and one dedupe), keep one project with several products. If mixing their accounts would be wrong, make two projects.

Product — what you’re selling

A Product lives inside a project and represents something you want to sell. A project can have multiple Products — each with its own positioning, fit criteria and campaigns.

Bucket	Holds
Identity	`name`, `slug` (auto-generated, suffixed on collision within the project)
Positioning	`description` — long-form, the AI’s primary anchor when it drafts fit criteria and scores accounts
Discoverability	`website_url` — the AI visits this when it drafts the fit criteria
Defaults	`communication_language` — drives outbound when neither Account nor Campaign override
Scoring calibration	`example_good_urls`, `example_bad_urls` — 2–3 of each, the single biggest lever on scoring quality after the fit criteria
Lifecycle	`archived_at`, `created_at`, `updated_at`, `created_by`
Related	One set of fit criteria per purpose; many Campaigns; one fit score per Account and purpose it’s been scored for

The description field is the single most important field on the product. The AI uses it to draft your fit criteria and to score accounts; vague descriptions produce vague fit criteria and noisy scores. Two paragraphs minimum, specific about who the product is for and who it isn’t.

Fit criteria live on the Product

The fit criteria are attached to the Product, one set per purpose, not to the Campaign. You find them under Settings → Products, in each product’s Fit criteria section. Campaigns of the same product and purpose share the same fit criteria; those without a scoring brief also share the same fit scores, so rescoring one benefits the others, the Accounts list and Today. A campaign with its own scoring brief keeps its own scores. See Fit criteria and fit score.

If you need a fundamentally different audience for the same product (e.g. enterprise vs SMB, EU vs US, agencies vs direct sellers), the right move is usually to create a second Product with its own fit criteria — not two campaigns of the same product. See the heuristic below.

When should I make a second product vs another campaign?

Signal	What it means	Action
Same product, different geography or segment, same fit criteria	One audience, you want to slice by market or vertical.	One Product, multiple Campaigns.
Same offering but the fit criteria change meaningfully (size band, sector, buying signals)	The model would score the audiences differently.	Two Products, each with its own fit criteria.
Different positioning of the same software	The what is identical, the for whom differs.	Two Products.
Truly separate offerings (different SKU, billing, sales motion)	These are distinct products in any business sense.	Two Products.

Rule of thumb: if you would write the fit criteria differently, it’s a different Product. Splitting on fit criteria keeps each product’s scoring sharp; splitting on language or geography alone wastes the calibration work.

Why this matters for scoring

Scoring is per product and purpose: one fit score per account for, say, the sales purpose of a product. The same account showing up in three campaigns of the same product and purpose gets scored once (unless a campaign has its own scoring brief, which keeps its own scores). That keeps AI cost down and scores consistent: an account doesn’t suddenly drop from Strong fit to Good fit because you started a new campaign. You don’t even need a campaign: Rank on the Accounts list scores any filtered list against a product’s fit criteria. See Rank a list without a campaign.

The calibration feedback loop is also per product and purpose — every Shortlist or Not a fit you decide one account at a time on a campaign’s Review tab feeds back into that product’s future scores for that purpose, not the project’s (bulk decisions never do). So a noisy review pass on Product A doesn’t leak into Product B’s scoring quality. See How scoring works.

If you swap a campaign’s product (allowed, as long as the new product belongs to the same project), the campaign’s accounts will need to be rescored against the new product’s fit criteria. LeadHunter handles that with a single click in the UI.

Archive vs delete

Both Product and Campaign support archiving — a soft-hide that keeps every related row in the database (campaigns, conversations, scores, expenses, audit trail) but hides the item from default list views. Toggle Show archived to see them again.

Action	Effect
Archive a Product	Hidden from the products list. All campaigns of that product also disappear from default lists unless un-archived separately. Re-activating is one click.
Delete a Product	Refused if any Campaign references it — archive instead. Once safe, hard-delete removes the row permanently.
Archive a Campaign	Hidden from default lists; every conversation, score, expense, and audit-trail entry is preserved.
Delete a Campaign	Name-confirmed (you type the exact campaign name). Removes the campaign’s account list, review decisions, expenses and, if it had its own scoring brief, its own scores. Conversations stay on each account (no longer tied to a campaign); the product’s fit criteria and the Accounts themselves are never affected.

A campaign’s archive and delete actions are on its Settings & costs tab, under Duplicate, archive or delete.

Bias toward archiving. Deletes are permanent and the data they take with them is often what makes the next campaign sharper.

Cross-project boundaries

Two reminders about what can and can’t cross the project boundary:

What doesn’t cross: accounts, scores, campaigns, expenses, custom fields, saved views, channels, webhooks, conversation history, audit trails. Everything operational — even between two projects of the same organization.
What does cross: your User profile, your communication language, your Recent entities list. These follow you across every project you belong to.

The dedupe stack is also project-scoped, which means the same business legitimately existing in two projects (e.g. an agency’s two clients both reach out to Acme Corp) will be two unmerged rows. That’s the right answer — they’re operationally independent.