Voice-AI voor klanten beheren: multi-tenant set-up, facturatie en supportgrenzen

Voice-AI voor klanten beheren is een ander vak dan één agent goed bouwen. Of het schaalt voorbij vijf accounts, hangt af van de structuur: hoe klantdata gescheiden is, hoe het gebruik van elke klant op de juiste factuur terechtkomt, wie een agent mag wijzigen en wat je op vrijdagavond wel en niet oplost.

Bureaus, BPO's en platforms die AI-stemagents doorverkopen, lopen tegen dezelfde drie muren aan, in dezelfde volgorde: tenancy, toewijzing van facturatie en support.

Zo richt je elk daarvan in voordat het een probleem wordt, plus de afspraken over offboarding die je het beste maakt zolang iedereen nog tevreden is.

TL;DR

• Scheid elke klant vanaf dag één op workspace-niveau. Scheiding achteraf aanbrengen nadat tien klanten één workspace delen, is een migratie, geen instelling.
• Workspaces maak je handmatig aan. Er is geen provisioning-API, dus stel het onboardingdraaiboek vroeg op.
• Nummers zijn het rommeligste onderdeel. Bepaal wie ze koopt, wiens naam op de beller-ID staat en wat er bij vertrek met een geporteerd nummer gebeurt.
• Toewijzing van facturatie komt uit de gebruikstotalen van de eigen workspace van elke klant, dus stem af per workspace in plaats van tegen één samengevoegde rekening.
• Leg vast wie een agent mag wijzigen. Ongecontroleerde wijzigingen door de klant en wijzigingen die alleen de leverancier mag doen, gaan allebei mis, in tegengestelde richting.
• Supportgrenzen zijn een prijsbeslissing. Definieer het aantal inbegrepen wijzigingen per maand, responstijden per ernst en wat buiten de scope valt.
• Leg de offboardingvoorwaarden vast in het eerste contract: vrijgave van nummers, export van opnames en wat er met de agentconfiguratie gebeurt.

Wat multi-tenant hier echt betekent

Multitenancy betekent dat één systeem veel klanten bedient en tegelijk de data, configuratie en gebruikers van elke klant gescheiden houdt. Voor een voice-AI-bureau moet die scheiding op vier vlakken tegelijk standhouden.

• Data. Gespreksopnames, transcripties en alle klantgegevens waar de agent van de ene klant mee werkt, mogen niet zichtbaar zijn voor een andere klant.
• Configuratie. Agents, prompts, kennis en doorschakelregels horen bij één klant, en een wijziging bij de een mag de ander niet raken.
• Toegang. Jouw team heeft toegang nodig tot alle klanten, elke klant tot de eigen omgeving, en niemand tot die van een ander.
• Gebruik. Minuten en gesprekken moeten per klant te tellen zijn, want dat is de factuur.

Heb je de eerste drie goed, dan wordt de vierde makkelijk. Heb je de eerste drie fout, dan wordt de vierde een spreadsheet die je elke maand met de hand bijhoudt.

Eén workspace per klant, of één workspace met veel agents?

Eén workspace per klant, in bijna alle gevallen.

De agents van alle klanten in één workspace zetten, is sneller ingericht en levert drie problemen op die erger worden naarmate het team groeit.

1. Je kunt een klant geen inzicht geven in de eigen gesprekken zonder die van alle anderen bloot te geven.
2. Gebruik komt binnen als één totaalgetal dat je vervolgens moet opsplitsen.
3. Een verkeerde wijziging of verwijdering raakt de live agent van de verkeerde klant.

Scheiding op workspace-niveau met rolgebaseerde toegang lost alle drie op, en dat sluit aan op hoe Retell zaken scheidt: elke workspace is een volledig geïsoleerde omgeving, met eigen agents, API-sleutels, leden, webhooks, telefonie-instellingen en facturatie. De ontwikkelaarsdocumentatie is het startpunt voor al het andere, maar provisioning gaat handmatig. Retell biedt geen API om workspaces aan te maken, te verwijderen of te wisselen, dus elke nieuwe klantworkspace richt je met de hand in via het dashboard. Reken per onboarding op die tijd en zet de stappen in een draaiboek vóór klant elf in plaats van erna.

Twee situaties rechtvaardigen een gedeelde workspace: een handvol piepkleine accounts met een identieke agent waarbij geen enkele klant ooit directe toegang krijgt, en een pilot die je wilt migreren. Voor beide heb je een expliciet plan nodig voor de dag dat dit niet meer klopt.

Hanteer vanaf klant één een naamgevingsconventie: klantcode, use case, omgeving, in die volgorde, op elke agent, elk nummer en elke kennisbank. Op dag één kost het niets en later bespaart het je een middag per incident.

Telefoonnummers, beller-ID en porteren

Nummers zorgen voor meer frictie met klanten dan wat dan ook in de stack, omdat het het enige deel van de set-up is dat de klant al bezit.

Drie beslissingen die je vóór de eerste lancering neemt.

• Wie het nummer koopt. Nummers die onder jouw account zijn gekocht, zijn eenvoudiger te beheren en lastiger over te dragen. Nummers die de klant bezit en naar de agent laat verwijzen, zijn het omgekeerde. Kies per klant en leg het vast in de overeenkomst.
• Porteren of doorschakelen. Klanten willen bijna altijd hun bestaande zakelijke nummer houden, en velen denken dat dat niet kan omdat de set-up hun een nieuw nummer aanbiedt. Het bestaande nummer doorschakelen naar de agent is meestal de snellere route en je hoeft hun provider helemaal niet aan te raken.
• Wiens identiteit zichtbaar is bij uitgaande gesprekken. Bij uitgaande gesprekken moet het merk van de klant verschijnen, niet het jouwe. Branded beller-ID en geverifieerde telefoonnummers bepalen of het gesprek überhaupt wordt aangenomen, en dat telt zwaarder dan het belvolume.

Eén valkuil die het benoemen waard is. Koop je uit gemak nummers onder je eigen account en vertrekt de klant later, dan beheer jij een nummer dat hun klanten bellen. Dat is een conflict dat op de loer ligt, dus spreek de vrijgavevoorwaarden af bij ondertekening en niet bij vertrek.

Waar de toewijzing van facturatie vandaan komt

Die komt uit gebruiksgegevens per klant, en die moeten tot op de minuut aansluiten op de gebruikstotalen van de workspace van elke klant.

Bouw de factuur op uit drie componenten en houd die gescheiden op de rekening van de klant.

Stem maandelijks af, niet per kwartaal. Als een klantfactuur en het workspacegebruik van die klant niet overeenkomen, zit het verschil bijna altijd in een nummer of agent in de verkeerde workspace, en dat vind je veel makkelijker binnen 30 dagen.

Gebruiksgegevens per workspace maken deze rekensom overzichtelijk, omdat het bedrag dat je aan een klant doorbelast het bedrag is dat die workspace in rekening is gebracht. Elke workspace heeft een eigen betaalmethode, tegoed, facturen en gebruikstotalen, dus aan het eind van de maand hoef je geen samengevoegde rekening uit elkaar te halen. Lees de hele rekening door wanneer je je factuur ontwerpt. Terugkerende kosten voor telefoonnummers, extra concurrency, kennisbanken, geverifieerde nummers en SMS staan naast het gebruikstarief, en die horen in je vaste post per klant, niet in de doorbelasting. Bekijk het huidige prijsmodel voordat je je factuur erop inricht.

Voor de commerciële kant beschrijft hoe bureaus AI-stemagents prijzen vier margemodellen die een verlenging overleven.

Voeg aan hetzelfde maandelijkse ritueel een margecheck toe: minuten per klant, omzet per klant en supporturen per klant, in één overzicht. Het account dat stilletjes geld kost, is meestal dat van de prettigste klant.

Wie is eigenaar van de agent als de klant een wijziging wil?

Iemand moet dat zijn, en het antwoord hoort vóór de lancering op papier te staan in plaats van tijdens een incident ontdekt te worden.

Beide uitersten gaan mis. Kun alleen jij wijzigingen doorvoeren, dan word je de bottleneck bij elk feestdagenbericht en elke prijsaanpassing, en ervaart de klant jouw ticketwachtrij als het product. Kan de klant alles wijzigen, dan past iemand op vrijdag een live prompt aan en krijg jij daar op maandag een telefoontje over.

Het werkbare midden is een verdeling op basis van risico.

• Klant wijzigt zelf: openingstijden, feestdagenberichten, FAQ-antwoorden in de kennisbank, ontvangers van meldingen.
• Jij wijzigt, dezelfde dag: formulering van de prompt, kwalificatievragen, doorschakelregels, escalatiedrempels.
• Projectwerk: nieuwe gesprekstypes, nieuwe integraties, alles wat de boekingsflow of een bronsysteem raakt.

Wat deze verdeling veilig maakt, is versiebeheer en een testroute. Wijzig in een niet-productieversie, test die met gesprekken en zet hem dan live. Zonder dat is elke wijziging een live experiment op de klanten van je klant. De regels voor gespreksoverdracht zijn die waarbij je het strengst moet zijn, want een kapotte doorverbinding is onzichtbaar in het dashboard en overduidelijk voor de beller.

De reden om dit in eigen hand te houden in plaats van bij een platformleverancier is snelheid, en dat is de pijler waar het hele operationele model op rust. Jij bent eigenaar van de verbetercyclus voor de klantervaring van elke klant in je portfolio. Anders dan bij managed AI-leveranciers en BPO's wordt een wijziging geen ticket, geen wachtrij en geen nieuwe SOW. Op het hele platform loopt 80% van de productieminuten via agents die klanten zelf bouwen en beheren, precies de constructie die jij je klanten een niveau lager aanbiedt.

Als degene die het mislukte gesprek hoorde het diezelfde middag kan oplossen, worden agents elke week beter. Als elke wijziging een ticket bij de leverancier is, verslechteren agents naarmate het bedrijf van de klant verandert.

Supportgrenzen: niveaus, responstijden en wat je weigert

Support is waar de marge van een bureau verdampt, dus die moet net zo strak worden vastgelegd als de prijs.

Leg drie dingen vast in de overeenkomst.

1. Inbegrepen wijzigingen per maand. Een getal, geen gevoel. Alles daarboven is een wijzigingsverzoek met een prijs.
2. Ernstniveaus en responstijden. Een agent die geen gesprekken aanneemt is iets anders dan een tekstaanpassing, en die horen niet dezelfde responstijd te hebben.
3. Expliciet buiten scope. Hun CRM dat plat ligt, een storing bij hun provider, een wijziging aan hun eigen websiteformulier en alles wat een beslissing vereist die alleen zij kunnen nemen.

Een ernsttabel die klanten zonder discussie accepteren, ziet er meestal zo uit.

Wat je weigert: onbeperkte beschikbaarheid, ongeprijsde herbouw en verantwoordelijkheid voor systemen waar je geen controle over hebt. Door deze te weigeren blijft de rest van je dienstverlening houdbaar bij twintig accounts.

Nog één grens die echt tijd bespaart. Laat de klant problemen met gesprekken via één kanaal melden, met de gespreks-ID erbij. Een screenshot van een sms van de klant van je klant is geen bugmelding, en het gesprek zoeken waar het om gaat, kan langer duren dan de oplossing zelf.

Wat je monitort over je hele klantenportfolio

Monitor op portfolioniveau, niet per klant, anders zie je alleen het probleem dat de luidste klant heeft opgemerkt.

• Aanname- en voltooiingspercentage per agent. Een daling hier is het vroegste signaal dat er stroomopwaarts iets kapot is.
• Succespercentage van doorverbindingen. Mislukte doorverbindingen zijn de meest voorkomende stille fout en het schadelijkst voor de klanten van je klant.
• Trend in gemiddelde gespreksduur. Een stijgende duur betekent dat de agent meer afhandelt, wat goed is, of dat hij in lussen vastzit, wat dat niet is.
• Redenen voor escalatie en onopgeloste gesprekken. De terugkerende reden waarom een agent een gesprek niet kon afhandelen, zijn je verbeteringen voor volgende week, voor elke klant met een vergelijkbare agent.
• Gebruik versus plan per klant. Signaleer het account dat je prijsmodel dreigt te breken voordat de factuur dat doet.

Dit is wat een portfolio met meerdere klanten beheersbaar maakt voor een klein team. Analyse na het gesprek geeft je het verslag per gesprek, en AI-kwaliteitsborging beoordeelt gesprekken op criteria die jij bepaalt, zodat je de fouten vindt waar de klant nog niet over heeft geklaagd. Die oplossen is het verschil tussen een verlengingsgesprek en een reddingsoperatie.

Lever je via een bureauplatform dat je klanten al gebruiken, controleer dan vroeg de integratieroute. De Go High Level-integratie is een van de meest gebruikte routes, en hoe leads en gespreksuitkomsten terugvloeien naar het bestaande systeem van de klant bepaalt meestal of die de uitrol als afgerond beschouwt.

Offboarding zonder conflict

Spreek het vertrek af in het eerste contract, want elke voorwaarde is nu makkelijk op te schrijven en later omstreden.

1. Vrijgave van nummers. Wie eigenaar is van elk nummer en hoe lang een portering of vrijgave duurt.
2. Opnames en transcripties. Wat wordt geëxporteerd, in welk formaat en wat je daarna verwijdert, met de bewaartermijn erbij.
3. Agentconfiguratie. Of de klant de prompts en flowlogica krijgt, of dat dat jouw werkproduct is. Beide antwoorden zijn te verdedigen. Zwijgen niet.
4. Opzegtermijn en eindfactuur. Inclusief hoe het gebruik in de laatste gedeeltelijke maand wordt gefactureerd.
5. Bevestiging van dataverwijdering. Vooral als de klant in een gereguleerde sector zit en dat op papier nodig heeft.

Klanten onderhandelen hier zelden over bij ondertekening en vragen er altijd naar bij vertrek. Door ze vroeg vast te leggen laat je bovendien zien dat je dit eerder hebt gedaan, en dat helpt de deal te sluiten waarin je ze opneemt.

De checklist voor de eerste tien klanten

Richt je dit nu in, doe dan het volgende in deze volgorde.

1. Eén workspace per klant, met de hand aangemaakt in het dashboard, met een naamgevingsconventie voor agents, nummers en kennisbanken.
2. Rolgebaseerde toegang, waarbij klantgebruikers alleen toegang hebben tot hun eigen workspace en je eigen team in elke klantworkspace wordt uitgenodigd met de rol die dat werk vereist. Rollen worden per workspace toegekend, en het uitnodigingsvenster biedt Admin, Developer en Member.
3. Eigendom van nummers en beller-ID per klant bepaald en vastgelegd in de overeenkomst.
4. Maandelijkse gebruiksafstemming per klant, tegen de gebruikstotalen van de workspace van die klant.
5. Een verdeling van wijzigingsrechten op basis van risico, plus een route van testen en dan live zetten voor alles wat live is.
6. Een ernsttabel met responstijden en een expliciete lijst van wat buiten scope valt.
7. Een monitoringoverzicht op portfolioniveau met aannamepercentage, succes van doorverbindingen en gebruik versus plan.
8. Offboardingvoorwaarden in het eerste contract.

Niets hiervan is moeilijk. Alles is veel lastiger na klant tien dan vóór klant één.

Veelgestelde vragen

Hoe houd je klantdata gescheiden als je AI-stemagents voor veel klanten beheert?

Gebruik één workspace per klant met rolgebaseerde toegang, zodat opnames, transcripties, configuratie en gebruik tot die klant beperkt blijven. Elke workspace is een volledig geïsoleerde omgeving. Beperk klantlogins tot hun eigen workspace en nodig je eigen team uit in elke klantworkspace met de rol die dat werk vereist, want rollen worden per workspace toegekend en niet daarboven. Het uitnodigingsvenster biedt Admin, Developer en Member. Controleer waar een bepaalde rol bij kan voordat je een klant een login geeft, want scheiding is precies wat je verkoopt.

Moet elke klant een eigen telefoonnummer hebben?

Ja. Of de klant is eigenaar van het nummer en schakelt het door of porteert het naar de agent, of jij koopt het namens hen met schriftelijk vastgelegde vrijgavevoorwaarden. Een nummer delen tussen klanten maakt toewijzing en belleridentiteit onmogelijk.

Hoe factureer je klanten voor voice-AI-gebruik?

Factureer drie aparte posten: platformgebruik op basis van de gebruiksgegevens van de workspace van die klant, vaste kosten per klant zoals nummers en integraties, en je eigen werk als retainer of wijzigingstegoed. Stem maandelijks af, workspace voor workspace, want elke workspace heeft eigen facturen en gebruikstotalen.

Moeten klanten hun eigen agents kunnen bewerken?

Geef ze de onderdelen met laag risico, zoals openingstijden, feestdagenberichten en de inhoud van de kennisbank, en houd prompts, doorschakelregels en integraties bij je team achter een route van testen en dan live zetten.

Welk supportniveau moet een bureau toezeggen?

Definieer ernstniveaus in plaats van één responstijd. Gesprekken die niet worden aangenomen, rechtvaardigen een reactie buiten kantooruren; een tekstwijziging niet. Leg daarna vast hoeveel wijzigingen per maand zijn inbegrepen en wat buiten de scope valt.

Wat gebeurt er met de agent als de klant vertrekt?

Wat er in je contract staat. Regel de vrijgave van nummers, export van opnames, dataverwijdering en of de agentconfiguratie wordt overgedragen. Beslis het bij ondertekening, want bij vertrek wordt het een onderhandeling.

Beheer één klant of honderd met dezelfde set-up

Retell is een Customer Experience AI-platform voor autonome klantrelaties. Richt één klantworkspace in, laat de echte gesprekken van die klant er een week doorheen lopen en controleer daarna de isolatie, de gebruiksgegevens en de gespreksbeoordeling aan de hand van deze checklist voordat je de tweede onboardt. Start een pilot met je eigen gesprekken.

##