KoltrixRunning sales and support from one inbox without collisions
When hello@ gets both prospects and customers, sales and support collide. Rules for spotting intent, splitting ownership and handing off new customers.
On this page(9 sections)
- Rule 1: Identify intent on the first read
- Rule 2: Sales owns pre-purchase, support owns customers
- Rule 3: Trials belong to support, with sales watching
- Rule 4: Hand over explicitly when a lead becomes a customer
- Rule 5: No pitching in support threads
- Rule 6: One voice per conversation
- A collision, replayed
- Rule 7: Review the boundary monthly
- When to split the inbox
- Bottom line
Early-stage companies usually have one public address, and everything goes there: pricing questions, bug reports, partnership offers, refund requests. That's fine with two founders. With a salesperson and a support person sharing it, collisions start: two people replying to the same prospect, a sales follow-up landing in the middle of an angry support thread, or a hot lead waiting a day because it looked like a support question.
You don't necessarily need separate inboxes to fix this. You need a few clear rules. This playbook lays them out.
Rule 1: Identify intent on the first read
Every email in a shared sales-and-support inbox gets one quick decision: is this person buying, or using?
Signals that it's sales:
- The sender isn't a customer (no account, unfamiliar domain).
- They ask about pricing, plans, team size, contracts or security questionnaires.
- They're comparing you to alternatives or asking for a demo.
- An existing customer asks about adding seats, upgrading or a new team joining.
Signals that it's support:
- The sender has an account and is asking how to do something.
- Something is broken or behaving unexpectedly.
- Billing questions about charges that already happened.
- Cancellation or downgrade requests.
Labels make this decision visible. Two labels, sales and support, applied during the first pass, are enough for most small teams. If you already sort mail by intent, sales leads and support requests map directly onto those intents.
Rule 2: Sales owns pre-purchase, support owns customers
The cleanest split is based on the customer lifecycle:
| Situation | Owner | Why |
|---|---|---|
| Prospect asking about pricing or fit | Sales | Pre-purchase conversation |
| Prospect on a free trial asking how-to questions | Support, with sales informed | They're using the product; help matters most |
| Prospect asking a technical pre-sales question | Sales, with support's help | Sales stays the point of contact |
| Paying customer with a problem | Support | Solving problems builds trust |
| Paying customer asking to upgrade or add seats | Sales | Expansion conversation |
| Paying customer wanting to cancel | Support | Respectful, fast handling |
| Partnership or vendor proposal | Founder or partnerships owner | Neither sales nor support |
Write this table down and share it. Most collisions come from situations nobody explicitly decided.
Rule 3: Trials belong to support, with sales watching
Free trials are where the boundary blurs most. A trial user asking how to connect their domain is a support question. Answer it quickly and well, because a trial user who gets stuck rarely converts.
Sales can follow the thread and reach out separately, at the right moment, about plans or a call. What sales shouldn't do is jump into a how-to thread with a pitch.
Rule 4: Hand over explicitly when a lead becomes a customer
When a prospect signs up and pays, the relationship changes hands. Make the handover visible rather than letting it happen by accident:
- Sales writes a short handover note: what the customer bought, what they care about, anything promised during the sales process, and who the main contacts are.
- Sales introduces support in a short email: "Going forward, [support address] is the fastest way to get help, and [name] on our team will look after you."
- Sales stays reachable for commercial questions: renewals, upgrades, contract changes.
The handover note matters most. The worst post-sale experience is a customer reminding support of a promise sales made, and support having no idea it was made.
A template for the note:
Handover: [Customer name]
Plan / contract: [details]
Main contacts: [name, role, email] for each
Why they bought: [one or two lines]
Promises made: [features, dates, discounts, special terms]
Watch out for: [concerns raised during sales]
Sales contact: [name], for renewals and expansion
Rule 5: No pitching in support threads
A customer who wrote in because something broke doesn't want to hear about the annual plan. Selling into a support thread damages trust in both directions: the customer feels like a target, and the support person loses credibility.
The exceptions are narrow and customer-led:
- The customer explicitly asks about a plan or feature that would solve their problem. Answer factually, and offer to connect them with sales if they want details.
- The problem is genuinely caused by a plan limit. Explain the limit plainly, and mention the options without pressure.
If sales sees an expansion opportunity in a support thread, they should wait until the issue is resolved and then reach out separately.
Rule 6: One voice per conversation
Two people replying to the same prospect with different answers is the classic shared-inbox collision. Prevent it with a simple convention: whoever replies first owns the thread, and anyone else who wants to contribute does so internally, not in the customer thread.
If ownership needs to change, say so in the reply ("I'm bringing in my colleague Sam, who handles pricing") so the customer knows who to expect.
A collision, replayed
Picture a four-person company. A prospect emails hello@ asking whether the product supports single sign-on. The support lead sees "SSO," assumes it's a setup question, and replies with a link to the configuration docs. An hour later the salesperson replies to the same thread with an offer to schedule a demo and a note that SSO is only on the higher plan. The prospect now has two answers, from two people, that don't quite fit together, and wonders whether anyone talks to each other.
Every rule above would have prevented it. Intent was misread on the first pass (an unfamiliar sender asking about plan features is a sales question). Ownership wasn't clear. And the second person replied in the customer thread instead of talking to their colleague first.
Rule 7: Review the boundary monthly
Spend ten minutes a month looking at threads where sales and support both touched the conversation:
- Were any leads answered slowly because they looked like support?
- Did anyone pitch inside a support thread?
- Did any new customer arrive without a handover note?
- Were there situations the ownership table didn't cover?
Update the table when you find a gap.
When to split the inbox
A shared inbox stops working well when volume makes the first-pass sort a job of its own, when sales and support need very different response expectations, or when access needs differ. At that point, separate addresses (for example, sales@ and support@) with shared mailbox access for both teams usually helps, while keeping the same ownership rules for mail that lands in the wrong place.
Bottom line
Sales and support can share one inbox if everyone sorts by intent on the first read, ownership follows the customer lifecycle, new customers are handed over with a written note, and nobody pitches in support threads. Write the rules down, keep one voice per conversation, and check the boundary monthly.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
