Who supports the customer when a tech partnership breaks
Who supports the customer when a technology partnership breaks: L1 and L2, escalation, status page, and what to put in the agreement before the first outage.
The integration is live, a customer depends on it for a daily job, and then it stops. They file a ticket with you. They file a ticket with the partner. Each company says the problem is on the other side. Two days later the customer is still down, and the partnership is now a support incident wearing a logo.
Support is the part of a technology partnership nobody wants to design while the announcement is being written. It is also the part customers remember. A pairing that fails in a clear, owned way can recover. A pairing that fails into a gap between two companies teaches the customer not to trust either of you.
This post is the support model you should write before the first outage: who takes L1, who takes L2, how escalation works, what a status page is for, and what belongs in the agreement. It is not a promise that nothing will break. It is a way to make sure someone is on the hook when it does. If you are still papering the deal, read this next to SaaS partnership agreements. The support clause is one of the terms that actually get used.
The 60-second version
If you only read one section, read this one:
- Name an owner for the customer before you launch. "We'll figure it out" is how tickets bounce.
- L1 is the first human the customer talks to. Decide which company that is, and train them on the pairing, not only on their own product.
- L2 is the team that can see the integration internals. That is usually the company that built and operates the connection, with a path into the partner's engineering.
- Escalation needs a named channel and a clock, not a generic "contact your partner manager."
- A status page (or an equivalent public note) stops duplicate panic when the break is on one side and many customers will feel it.
- Put L1, L2, escalation, and notice in the agreement in plain language. If it is only in a Slack channel, it will vanish when someone changes jobs.
- A small team can run this with a runbook and a duty path. You do not need a dedicated partner support org to be responsible.
Why support is the partnership's real test
Customers do not experience your org chart. They experience whether the job still runs.
When two products are connected, failure modes cross the boundary: auth expired, the partner changed a field, your job queue stalled, their surface had an incident, a customer misconfigured a mapping. The customer cannot triage that. If your L1 says "that's their problem" and their L1 says the reverse, you have created a third product: the argument.
This is why support belongs in the partnership lifecycle as an operating concern, not as a launch afterthought. Launch week is when you still have attention. Write the runbook then. After launch, you only write it during an incident, which is the worst possible time.
Trust is practical here. People decide whether a vendor is credible from how problems are handled as much as from the homepage. That is consistent with what research on trust and credibility online has said for years: specific, honest communication beats a polished silence. A pairing with a clear "here's what broke and who owns it" will outlast a pairing that only looks good in a deck.
L1, L2, and who actually picks up
Define the tiers in language both support teams can use.
L1 is intake: reproduce the symptom, collect the identifiers (account, connection, timestamp, error text), check the obvious (auth, paused connection, known incident), and either resolve the simple cases or package a clean handoff. L1 should know the pairing well enough to tell a misconfiguration from a platform outage. They do not need to read the integration's internals.
L2 is diagnosis across the boundary: logs, job status, partner-side errors, a decision about whether the fix is on your code, their surface, or the customer's setup. L2 is almost always the team that operates the integration. If you built it, that is you, even if the ticket started on the partner's side.
Partner engineering is the third stop, not the first. You escalate into it when L2 has evidence the break is on their surface: a failing endpoint, a silent schema change, a regional incident they have not posted. Do not send customers there directly.
Who should own L1 depends on where the customer thinks the product lives.
| Where the customer lives | Sensible L1 | Sensible L2 |
|---|---|---|
| They bought your product, connected to the partner | Your support | Your integration owners, then partner engineering |
| They bought the partner, installed you from a marketplace | Often the partner's support, with a warm handoff to you | You, as the integration operator |
| Both are equal in the workflow | Pick one named L1 (usually the company that owns the connection UX) | The operator of the connection |
The failure is split-brain L1: "file with both of us." Customers will, and you will duplicate work while they wait. Pick a default. Publish it on the integration page and in the in-app error. "Contact us first, we will pull the partner in" is a complete sentence.
Train L1 with a short pairing FAQ: top ten symptoms, what to collect, when it is a known incident, when to escalate. That is partner enablement for support, not only for sales. A seller who can pitch the pairing is useless if support cannot triage it.
Escalation, clocks, and the status page
Escalation is a path, not a feeling.
Write it as: L1 to L2 inside your company (named queue, named urgency), L2 to a partner channel (email alias, Slack, partner portal ticket), and a backup person if the channel is silent. Put a clock on the backup: if no ack in X hours during business time, ping the partner manager. Do not make the only path "the AE who introduced us." That person will be on holiday.
Severity should be shared language. A single customer with a bad mapping is not the same as all connections failing. Agree two or three severities so you do not have to debate urgency during the incident.
A status page is for the cases where many customers will feel the same break. If you operate the integration, you need a way to say "we know, this is us" or "this is the partner, here is their incident." That can be a public status page, a banner in-app, or a note your L1 is allowed to send. Silence creates duplicate tickets and Twitter threads. Guessing which side is down, in public, creates a different problem. Confirm, then post.
When the partner has the incident, link to their status if they have one. Do not invent a root cause you have not seen. "We are seeing failures talking to [partner]; we have escalated; next update by [time]" is enough.
| Event | Customer-facing move | Internal move |
|---|---|---|
| Single-tenant misconfig | L1 resolves or guides | No status post |
| Your integration bug | Ack, status or banner if many are hit, fix note | L2 owns, postmortem if it was wide |
| Partner surface incident | Ack, point at their status if any, next update time | Escalate, do not argue in the ticket |
| Unknown | Ack, "we are diagnosing," collect IDs | L2, then partner if evidence says so |
After a wide incident, write down what you will change: a monitor, a runbook line, a contact. If you keep sunsetting broken pairings instead of operating them, that is a portfolio decision. See how to sunset a partnership. Support pain is often the first honest signal that a partnership is no longer worth keeping.
What to put in the agreement
If support only lives in a kickoff deck, it will not survive contact with legal, turnover, or a bad quarter.
Put four things in the partner agreement or in an exhibit both sides will actually find:
L1 default. Which company the customer contacts first for integration issues, and a commitment to take the ticket rather than bounce it.
L2 and escalation. A channel, a backup, and an expectation of acknowledgement. You will not get a consumer-grade SLA from a large platform. You can get a named path.
Notice. How they tell you about incidents and deprecations, and how you tell them. A status page URL, a mailing list, a portal. If there is no notice path, you will learn about breaks from customers.
Data for diagnosis. Permission to share the minimum identifiers needed to debug (account IDs, timestamps, error codes), under the existing data terms. Tickets stall when each side refuses to share the only facts that would help.
Do not write a fantasy SLA you cannot keep. Do not accept unlimited support burden for their product. Do not leave "reasonable commercial efforts" as the only sentence if you can name a channel instead.
A small team runs this with a one-page runbook, a duty rotation (even if that rotation is "whoever is on product support this week"), and the escalation alias in the agreement. Review the runbook when the product changes, not only after an outage. If you cannot staff L1 for a pairing, you are not ready to launch it, or you need the partner to be L1 and you to be a fast L2. That is a valid model. It is not valid if neither of you agreed to it.
Common mistakes, and the fix
Launching with no named L1. The fix: pick a default, publish it on the integration page, and train that queue on the pairing.
Telling the customer to "also file with them." The fix: you take the ticket, you pull the other side in. Split-brain intake is how incidents age.
Escalating through a salesperson. The fix: a durable alias or portal path, with a backup person. Sales is not a support on-call.
Posting nothing during a wide break. The fix: a short public or in-app ack and a next update time. Silence multiplies tickets.
Writing an SLA you will miss. The fix: a channel and an ack expectation you can keep. Missed SLAs are worse than modest, honest ones.
Leaving support out of the agreement. The fix: L1, escalation, notice, and diagnostic data in an exhibit. Kickoff slides do not bind anyone.
FAQ
Who should the customer contact first? Whoever you named as L1. Default to the company that owns the connection user experience, unless the partner's marketplace rules say otherwise. Publish it. Do not make the customer guess.
What is L2 in a tech partnership? The people who can diagnose the integration itself: logs, jobs, partner-side errors. Usually the team that operates the connection. They escalate into the partner's engineering when the evidence says the break is on that surface.
Do we need a public status page? You need a way to tell many customers the same true thing at once. That can be a status page, an in-app banner, or a script L1 is allowed to send. For wide breaks, pick one and use it.
What if the partner will not agree to an SLA? Ask for a named escalation path and notice of incidents, not a fake uptime number. Many platforms will not move on SLA language. They will often give you a channel.
How do we stop tickets bouncing? One L1 default, a packaged handoff (IDs, timestamps, error text), and a rule that the first company to take the ticket owns it until it is resolved or cleanly transferred.
Can a small team really support a pairing? Yes, if the runbook is short, L1 is trained on top symptoms, and escalation is not a scavenger hunt. If you cannot do that, delay launch or narrow who you let onto the integration.
What belongs in the agreement versus the runbook? Agreement: L1 default, escalation channel, notice, diagnostic data. Runbook: symptoms, how to collect IDs, severity, who is on duty this week. Do not put staffing rotas in the contract.
Further reading
- How to negotiate SaaS partnership agreements for the clauses this model should land in.
- The full lifecycle of a SaaS tech partnership for support as an operating stage, not a launch extra.
- Partner enablement 101 for training support, not only sales.
- When to sunset a partnership if support pain is telling you the pairing is done.
- What is a technology partnership? for why the integration, not the announcement, is the deliverable.
- Nielsen Norman Group on trust and credibility online.
- Due diligence, for checking whether a partner can actually support you before you build.
The short version
When a tech partnership breaks, the customer needs one front door, not two companies pointing at each other. Name L1, train them on the pairing, give L2 a path into the partner, and put a clock on silence. Use a status note when many customers will feel the same failure. Write L1, escalation, notice, and diagnostic data into the agreement so the model survives turnover.
You do not need a large support org. You need a runbook, a default owner, and the honesty to delay a launch you cannot triage. Support is how the partnership is judged after the webinar is forgotten. Design it before the first outage, not during it.
If you want a support and GTM model that matches a real pairing, that is what a Partner Audit is for. We review the partnership, the operating gaps, and what to put on paper before you scale the integration.