Originally published at ict.vision
When a reseller's AI voice agent does something wrong, the end customer complains to a brand that cannot fix it. The ticket then travels through the reseller to you, arriving with none of the audio, the persona configuration or the tool call log attached. Most B2B software solutions in ICT that added an AI agent over the last eighteen months did it without redrawing the support boundary underneath.
That is the whole problem in a paragraph. The rest of this is what to do about it.
Four hops before the ticket reaches anyone who can actually look at the call. Three of those hops are on your payroll.
The ticket arrives with none of the context you need
A white-label arrangement works because the reseller owns the customer relationship and you own the platform. For everything that came before AI, that split was clean. A call did not connect. A recording did not save. A number did not port. The reseller reproduces the symptom, sends you a call ID, and someone on your side looks it up.
An AI agent breaks the pattern in a specific way. The symptom is a decision, not a failure. There is no error code for "it put me through to billing when I asked about a delivery". Reproducing it means knowing what the agent heard, which persona was loaded, which tools were enabled at that moment, and what the model chose to do. Your reseller configured roughly half of that and can inspect none of it.
So the ticket arrives as prose. "Customer says the bot hung up on them, Tuesday afternoon, quite angry." Your tier 2 asks a clarifying question. The reseller asks the customer. A day passes. The answer comes back partial, so tier 2 asks again. Two working days of elapsed time to establish a call ID, which is the first thing anyone needed.
None of that time is billable and all of it is yours. That is the part vendors underprice when they add an AI tier to the price list.
What B2B software solutions in ICT actually take on when they add AI
The commercial pitch for white label ICT software has always been that the reseller gets a product without building one. Adding an AI agent quietly changes what "the product" includes.
Before, you shipped deterministic behaviour. A dialplan does the same thing every time, so a reseller who breaks something broke it by changing a setting, and the setting is visible in their own admin panel. Now you ship a system whose output depends on a prompt the reseller wrote, a tool list the reseller enabled, and a caller who mumbled. Two of those three are outside your control, and all three land in your logs.
There is a second-order effect that catches people out. Resellers talk to each other. One reseller's badly scoped tool permission produces an incident, the story circulates, and suddenly your AI tier has a reputation problem built entirely out of configurations you did not write. Deterministic software never had that failure mode, because nobody tells a war story about a misconfigured ring group.
The rows where ownership genuinely splits
Two rows sit entirely with the reseller and still generate vendor tickets, because the customer has no idea the reseller exists.
Most of that matrix is uncontroversial. The telephony and the transcript guards are yours, and nobody argues. Data retention is shared but the levers are yours. Disclosure that a caller is speaking to AI is a reseller obligation, since they hold the customer relationship and the jurisdiction.
The two rows worth fighting over are which tools the agent may call, and what those tools do once called. A reseller who enables a refund tool with no confirmation turn has created your incident. Worse, the second row is genuinely theirs to fix, because the webhook behind the tool runs on their infrastructure and you cannot see inside it. You will still be the one asked why it happened.
My honest read is that most vendors ship the tool registry as an open list because it demos well, and then spend the following year absorbing the consequences one ticket at a time.
Three controls that keep tickets at hop two
None of these require you to take back control of the reseller's configuration. They just move the diagnosis to where the configuration lives.
A per-call agent trace in the tenant panel. What the agent heard, what it decided, which tool it called, and the arguments it passed. If the reseller can open this themselves, most tickets end at hop two. This single feature is worth more to your support cost than any model upgrade.
Tool permissions with a default of read-only. Lookups and status checks can be on by default. Anything that writes, refunds, cancels or sends should be off until someone actively turns it on, and the panel should say in plain language what turning it on allows. Defaults are policy, not convenience.
A rejected-input counter per tenant. When your platform drops a transcript as implausible, log it and surface the rate. A reseller whose rejection rate is triple everyone else's has a line quality problem, and that is a conversation about their carrier rather than about your AI.
The third one is easy to skip and pays for itself the first time a reseller insists the agent is unreliable. Being able to answer with a number, on their tenant, against the fleet average, ends that argument in one reply.
What belongs in the reseller agreement
Contracts written for deterministic software tend to have a support annex that assumes reproducibility. Three additions are worth making before your AI tier gets busy.
First, define what a valid AI incident report contains. A call ID, a timestamp with timezone, and the tenant identifier. Tickets without those go back, politely, with a link to the trace view. This sounds bureaucratic until you count how many of your engineering hours currently go into establishing facts a form field could have captured.
Second, state that the reseller owns tool scope. If they enable a write action, the outcomes of that action are theirs, and your obligation is to show accurately what the agent did rather than to make the downstream system behave.
Third, put disclosure squarely with the reseller. They know which jurisdiction the end customer sits in and you do not. Give them the toggle and the wording, then let the obligation follow the relationship.
A partner running a multi-tenant PBX platform under their own brand has all of these questions in front of them the moment they turn an AI tier on. The same applies to outbound campaign platforms, where an agent holding a callback or do-not-call tool touches compliance directly rather than only touching customer experience.
The version of this that scales
You cannot stop resellers from configuring AI badly, and you should not want to, because the configurability is what they are buying. What you can do is make every bad configuration diagnosable by the person who created it.
That is a smaller engineering job than it sounds. A trace view, sane defaults on the tool registry and one counter. The alternative is a support desk that grows in proportion to your reseller count, which is exactly the economics white label was supposed to avoid.
Frequently asked questions
Should a white-label vendor restrict which AI tools resellers can enable?
Restricting the list outright tends to cost you deals, since configurability is a large part of the value. A better position is that write actions ship disabled, the panel explains in plain language what enabling one permits, and the audit trail records who turned it on and when.
Who is liable when a reseller's AI agent gives a customer wrong information?
Commercially it depends on your agreement, which is why the agreement needs updating. Practically the reseller holds the customer relationship and the jurisdiction, so the obligation sits with them. Your exposure is that you are the only party who can evidence what happened, which makes you a participant in every dispute whether or not you are liable in it.
Does giving resellers a call trace expose our platform internals?
Not if you scope it properly. The trace needs the transcript, the decision, the tool name and the arguments passed. It does not need model versions, prompt scaffolding or infrastructure detail. Resellers want to answer their customer, not to reimplement your stack.
How much support load does an AI tier actually add?
The pattern we see is that ticket volume rises modestly while time-per-ticket rises sharply, because diagnosis now requires context that travels badly between three parties. Measuring elapsed time to first useful fact is more informative than counting tickets.
Is this different for on-premises deployments?
It gets harder. With a hosted tenant you can at least look at the call yourself. On premises you have neither the configuration nor the logs, so a trace view the local administrator can read is not a convenience, it is the only diagnostic path you have.
Related resources
ICTPBX: multi-tenant, white-label PBX platform for service providers
ICTBroadcast: white-label outbound campaign and contact platform
Asterisk support and development: engineering help for partners running their own telephony stack
Top comments (0)