How to support software you resell

Define what gets fixed directly and what routes to the vendor before the first support ticket arrives. Not while a client is already waiting on an answer no one is sure who owns.

An admin approves every new account by hand. Nothing is created until then. We reply by email; no newsletter, no sequence.

app.salescrew.io/inbox
The unified reply inbox with classified threads

The short answer

  • Define the line between what an agency fixes directly and what gets escalated to the vendor before the first support ticket arrives. Do not decide it ad hoc while a client is waiting.
  • Reseller agreements vary on support obligations. Some vendors expect the reseller to handle first-line support entirely. Others support end clients directly whatever the reseller relationship. Check this specifically rather than assuming.
  • Whether a client knows they are being escalated to the vendor is a deliberate positioning choice, not something to leave ambiguous. Both a fully invisible escalation model and an open one can work if chosen on purpose.
  • Promising a support level the agency cannot deliver damages trust quickly once a client hits an issue with no clear path to resolution, especially if the gap was never disclosed.

Why the support boundary needs to be set before it is tested

A reseller relationship almost always splits support between what the agency can fix directly (configuration, workflow, account settings) and what needs the vendor's own support (a real product bug, an infrastructure issue). The trouble starts when this split is not defined until the first ticket that falls outside what the agency can fix. At that point the agency is figuring out the escalation process for the first time, while a client is already frustrated and waiting.

Defining the boundary up front means knowing, before any client hits it, which categories of issues the agency resolves directly and which get escalated. It means knowing what that escalation process looks like with the vendor, and roughly how long escalated issues take. This does not need to be a formal document shared with every client. It needs to exist internally, so the team is not improvising under pressure the first time it matters.

A support boundary worth defining upfront

Issue typeWho typically handles itWhat to confirm
Configuration and setup questionsThe reselling agency, directlyTeam has actual depth in the tool, not only familiarity
Workflow and best-practice questionsThe reselling agency, directlySame as above
A genuine product bugThe underlying vendorThe reseller agreement's actual escalation process and expected response time
Billing or account-level issuesDepends on the reseller agreementWhether the agency or the vendor owns billing for resold accounts

What to actually check with the vendor before reselling

Ask the vendor directly what support obligations exist for resold accounts. Does the vendor support end clients at all, or is the reseller expected to be the sole support contact? Confirm what the escalation path looks like when an issue is outside the agency's ability to fix, and what response time to expect. Promising a client a timeline the agency cannot control creates risk if the vendor's own response is slower.

It also helps to write down the support boundary somewhere the whole team can find, not only the person who negotiated the reseller agreement. A support rep fielding a ticket at 9pm should not have to guess whether an issue is a configuration question they can answer or a product bug that needs escalation. A short internal reference settles that question quickly and keeps response times consistent, whoever picks up the ticket.

Disclosure: SalesCrew is our product. Agencies reselling it get product support directly from the vendor side for real product issues. Configuration for a specific client's setup, pipeline stages, cadences, agent policy, is something the reselling agency typically owns, because it reflects decisions made for that client rather than a product defect. This split should still be confirmed directly as part of any reseller arrangement.

An undefined support boundary gets tested at the worst possible moment

The first time a client hits an issue outside what the agency expected to handle is rarely a good moment to work out the escalation process. Define and test the path to vendor support before a client ever needs it.

Questions

Should a client know they're being routed to the underlying vendor for some issues?
That depends on the reseller relationship and how the offering is positioned. Some agencies handle everything through their own support channel and escalate to the vendor invisibly. Others are open that certain issues go to vendor support. Either can work, but it should be a deliberate choice, not left ambiguous.
What is the risk of promising support you cannot actually deliver?
A client who hits an issue outside what the agency can fix, with no clear escalation path, tends to lose trust quickly. That is worse if the gap was not disclosed up front. Being clear about support boundaries before signing avoids this failure.
Does reselling software mean taking on the vendor's own support obligations?
Not automatically. That depends on the reseller agreement. Some vendors expect the reseller to handle first-line support entirely. Others provide direct support to end clients whatever the reseller relationship. Check this specifically rather than assuming.