Run outbound for several clients, one database each
Each client gets a separate Postgres project with its own sender pool, suppression list and approval queue. Seats stay unlimited on every tier.
- One database per client
- A sender pool per client
- An approval queue per instance
How SalesCrew runs outbound for many clients
- SalesCrew gives every client its own instance. That is a separate Supabase project with its own database, storage and MCP endpoint.
- Each SalesCrew client sends from its own mailbox pool, with daily caps per mailbox and per domain. Its suppression list is checked at freeze and again at send.
- Every send an agent drafts waits in that client's approval queue. Each tool call lands in that client's audit log, with the actor named.
- Snapshots copy your best client setup onto the next one, and seats are unlimited on every SalesCrew tier.
Shared workspaces mix clients in one database
Run cold email for six clients from one shared account, and their contacts, replies and opt-outs all sit in one place. You filter by client and hope nobody picks the wrong tag. A contact who unsubscribed from client A can still sit in client B's list, and you'll only find out when they reply angry.
SalesCrew removes the filter. Each client runs in a separate instance with its own database, so there's no other client's data to hide. Your operator opens the client's instance on its own subdomain. The list there only ever held that client's rows. See how to keep client data separate for the wider options.
Sending works the same way. Each instance holds its own sender pool: the mailboxes that client's campaigns go out from. Caps, cooldowns and bounce handling apply per pool, so one client's volume never spends another client's reputation.
What each client instance holds
Every row below exists once per client, inside that client's own database.
| What | Mechanism | Direction | Objects | Status |
|---|---|---|---|---|
| Client database | One Supabase project per client: Postgres, storage and edge functions | Stays with the client | Contacts, companies, deals, threads, files | Available |
| Sender pool | The client's mailboxes connected over IMAP/SMTP, sent through the mailbox-pool lane | Outbound mail, replies back in | Mailboxes, per-mailbox and per-domain daily caps, cooldowns | Available |
| Suppression | Checked when an audience is frozen and again at send time | Unsubscribes and bounces feed it | Suppressed addresses and domains | Available |
| Approval queue | Agent sends park in review; a person approves or rejects | Agent to person | Emails, LinkedIn messages, proposals | Available |
| Snapshot | Export from one instance, apply to another | Your template to the client | Stages, cadences, segments, ICPs, agent policy | Available |
| MCP endpoint | MCP over HTTP, per-user tokens scoped by channel, profile and area | Two-way | Every action in the app, as 140+ tools | Available |
Trigger to logged
One new client, from signed contract to the first logged reply.
- 1
Trigger: you sign a new client
You approve a new instance and pick the region the client's data should live in. SalesCrew creates a separate Supabase project for that client, with its own subdomain and MCP endpoint.
- 2
Apply your standard setup
Apply a snapshot from your best-running client. Stages, cadences, segments, ICPs and agent policy arrive in one step, and anything client-specific can be changed on screen or through an MCP tool.
- 3
Connect the client's mailboxes
Add the client's sending mailboxes over IMAP and SMTP. They form that client's pool, and credentials go into the instance's Vault, where nobody can read them back after entry.
- 4
Import the list and freeze an audience
Load the client's suppression list first, then import prospects into the Data Bank from CSV. Freezing an audience removes every suppressed contact before a single email is scheduled.
- 5
Drafts wait for a person
Cadence steps go out from the pool within the caps, with at least three days between touches per contact. Anything an agent writes waits in the approval queue until your operator approves it.
- 6
Replies land and get logged
Replies come back into that client's unified inbox. A reply pauses the cadence for that contact, an unsubscribe suppresses them, and the audit log records who or what did each step.
What it costs to run five clients
You'd run your own agency on the Agency tier at $1,200 a month. It adds the marketing module, marketplaces and every agent. Each client instance is priced at the tier its work needs. Most often that's Core at $299 a month, with the CRM, the inbox, cadences on the mailbox pool and the Data Bank.
Seats are unlimited on every tier. Your SDRs, your copywriter and the client's own sales lead can all log in to the same instance without a per-seat line on the invoice. Full tier details sit on the pricing page.
Load suppression before the first campaign
Questions
- Can one client's bounces or complaints hurt another client's sending?
- No. In SalesCrew each client's mailboxes, suppression list and bounce history live in that client's own database. A bounce or complaint in one instance adds the address to that instance's suppression list, and the next send checks it. Another client's pool never reads those rows, because they sit in a different Postgres project.
- How do I get the fifth client live as fast as the first?
- Export a snapshot from the client instance you trust most and apply it to the new one. The snapshot carries your pipeline stages, cadences, segments, ICPs and agent policy, so the new client starts from your best setup. Every one of those settings also has an MCP tool, so a script or an agent can apply the rest.
- Who approves the emails, my team or the client?
- You decide per instance. Every external send from an agent waits in that instance's approval queue, and roles set who may approve it. You can keep approval with your own operator or hand it to the client's sales lead. The audit log names who approved each send.
- How many people can work on each client?
- As many as you need. Seats are unlimited on every SalesCrew tier, so adding a copywriter or a second SDR to a client costs nothing extra. Core starts at $299 a month per instance.
- What happens to a client's data when they leave?
- They take it with them. A client's database exports as a full Postgres dump plus CSV files. On churn the instance turns read-only for export, and a person on your side deprovisions it after 90 days.
Give your next client their own instance
Request access, then apply your best client's snapshot to the new one.