Een RFP voor kwaliteitssoftware (request for proposal, of offerteaanvraag) is het document dat je naar leveranciers van kwaliteitscontrole stuurt, zodat je hun antwoorden op dezelfde vragen kunt vergelijken. Voor een contactcenter dekt het de dekking en nauwkeurigheid van de beoordeling, scorecards, kanalen en integraties, coaching, AI-agents, beveiliging, implementatie en prijs, met een gewogen scoreblad dat vastligt voordat het eerste antwoord binnenkomt.
In het kort
- Leg je eisen vast vóór de RFP: hoeveel je beoordeelt, op welke kanalen, wie beoordeelt en welke antwoorden een leverancier uitsluiten.
- Gebruik de 40 vragen hieronder, verdeeld over negen blokken, en vraag bij elk antwoord om bewijs in plaats van een ja.
- Geef elk antwoord 0 tot 3 punten volgens geschreven definities, weeg de blokken en behandel beveiliging en datavoorwaarden als een poort waar je wel of niet door komt.
- Het uitgewerkte voorbeeld laat zien waarom een nipte uitslag een beslisregel en een gescripte demo nodig heeft, geen langere spreadsheet.
- Vermijd de fouten die antwoorden onvergelijkbaar maken: open vragen, geen weging en prijs gescoord als een functie.
Dit artikel is de koopchecklist. Wil je zien hoe specifieke tools zich tot elkaar verhouden, lees dan onze vergelijking van kwaliteitsmonitoringsoftware. Selecteer je kwaliteitscontrolesoftware voor je klantenservice voor een groot supportteam, dan zijn de vragen hieronder de vragen die een koper ons zou moeten stellen.
Wat hoort er in een RFP voor kwaliteitssoftware?
Een RFP voor kwaliteitssoftware in een contactcenter bevat je context, je eisen, de vragen aan leveranciers, de scoremethode en de planning. Leveranciers antwoorden beter als ze je volumes, kanalen en helpdesk kennen, en jij vergelijkt beter als de scoring vooraf vastligt.
| Onderdeel van de RFP | Inhoud | Waarom het telt |
|---|---|---|
| Context | Licenties, maandelijks gespreksvolume, kanalen, talen, helpdesk, huidig kwaliteitsproces | Leveranciers stemmen hun antwoord af op jouw operatie in plaats van een standaardpresentatie te sturen |
| Eisen | Must-haves, wensen, knock-outcriteria | Scheidt wat je nodig hebt van wat goed klinkt in een demo |
| Vragen | De 40 vragen hieronder, met verzoeken om bewijs | Maakt antwoorden regel voor regel vergelijkbaar |
| Scoring | Schaal, weging, knock-outregels, wie scoort | Voorkomt dat de luidste stem achteraf beslist |
| Commerciële voorwaarden | In te vullen prijstabel, looptijd, verlengingsvoorwaarden | Inkoop vergelijkt appels met appels |
| Planning | Deadlines voor vragen, antwoorden, demo’s, besluit | Houdt het proces op weken in plaats van kwartalen |
Houd het document kort genoeg dat het productteam van de leverancier antwoordt, niet alleen sales. Veertig goed gekozen vragen leveren betere antwoorden op dan tweehonderd vragen uit een algemeen sjabloon.
Leg je eisen vast voordat je verstuurt
Je eisen komen uit vier interne beslissingen: hoeveel je beoordeelt, wie beoordeelt, welke kanalen tellen en hoe de tool moet koppelen. Elke beslissing maakt van een vage wens een vraag waarop een leverancier kan afhaken.
Stap 1: Bepaal de dekking die je nodig hebt
Een handmatig programma bekijkt meestal een kleine steekproef. Hangen beslissingen over individuele medewerkers, compliancecontroles of het toezicht op AI-agents af van kwaliteit, dan volstaat een steekproef zelden, zoals we uitleggen in ons artikel over waarom een steekproef van 3 % geen beslissingen per medewerker draagt (in het Engels). Schrijf op of je elk gesprek wilt laten beoordelen of een grotere steekproef sneller wilt reviewen.
Stap 2: Bepaal wie het laatste woord heeft over een score
Sommige teams willen volledig automatische beoordeling; andere willen dat AI een voorstel doet en een beoordelaar goedkeurt. Veel teams willen beide, op verschillende wachtrijen. De RFP moet vragen hoe elke modus werkt en hoe een beoordelaar de AI corrigeert.
Stap 3: Zet je kanalen en systemen op een rij
Noem elk kanaal dat op de scorecard moet (telefoon, chat, e-mail, messaging) en elk systeem waarin gesprekken staan. Een leverancier die chat goed beoordeelt maar telefonie als apart product behandelt, ziet er in de chatdemo sterk uit en faalt op je telefoonwachtrij.
Stap 4: Schrijf je knock-outcriteria op
Een knock-outcriterium is een antwoord dat een leverancier uitsluit, ongeacht de score. Gangbare voorbeelden: geen getekende verwerkersovereenkomst, geen ondersteuning voor je helpdesk, geen manier om te zien waarom een score is gegeven. Houd het op vijf of minder, anders blijft er niemand over.
De 40 RFP-vragen, per blok
Deze 40 vragen dekken de negen gebieden waarop kwaliteitstools voor contactcenters het meest verschillen. Kopieer ze met hun nummering in je RFP en vraag leveranciers elke vraag kort te beantwoorden, met het gevraagde bewijs.
Blok A: Dekking en beoordeling (6 vragen)
| # | Vraag | Wat een goed antwoord laat zien |
|---|---|---|
| A1 | Welk deel van onze gesprekken kunnen jullie beoordelen, en wanneer wordt elk gesprek beoordeeld? | Een concreet aandeel en moment, bijvoorbeeld elk gesprek zodra het is opgelost |
| A2 | Welke delen van de beoordeling zijn volledig automatisch en welke vragen een beoordelaar? | Een duidelijke verdeling, met beide modi beschikbaar |
| A3 | Hoe past een beoordelaar een automatische score of feedback aan? | Een bewerk- en goedkeurflow, met de wijziging vastgelegd |
| A4 | Hoe laten jullie zien waarom een score is gegeven? | Bewijs uit het transcript naast elk criterium |
| A5 | Hoe beoordelen jullie kritieke criteria, zoals het delen van kaartgegevens? | Kritieke criteria apart van gewogen criteria |
| A6 | Wat doen jullie met gesprekken waarover de AI onzeker is? | Doorsturen naar een menselijke wachtrij, geen stille gok |
Blok B: De scorecard en haar standaard (5 vragen)
| # | Vraag | Wat een goed antwoord laat zien |
|---|---|---|
| B1 | Kunnen we onze huidige scorecard ongewijzigd importeren? | Jouw criteria in jouw woorden, geen opgelegd sjabloon |
| B2 | Hoeveel geautomatiseerde criteria mogen we hebben, en zijn er limieten per abonnement? | Een aantal, per abonnement |
| B3 | Hoe wegen we criteria en gebruiken we verschillende scorecards per team, wachtrij of klant? | Weging per criterium en scorecards per team |
| B4 | Wat gebeurt er met toekomstige en eerdere scores als we een criterium wijzigen? | Een vastgelegde regel, liefst met versiegeschiedenis |
| B5 | Hoe gebruiken jullie onze kennisbank of procedures bij de beoordeling? | Jouw content als context, geen algemeen oordeel |
Voor het opbouwen van de scorecard zelf, zie onze gids voor een QA-scorecard voor klantenservice.
Blok C: Nauwkeurigheid en validatie (5 vragen)
| # | Vraag | Wat een goed antwoord laat zien |
|---|---|---|
| C1 | Hoe kunnen we automatische scores vóór livegang vergelijken met die van onze beoordelaars? | Een test op historische beoordelingen, per criterium |
| C2 | Hoe rapporteren jullie de overeenstemming tussen automatische en menselijke scores? | Overeenstemming per criterium, niet één nauwkeurigheidscijfer |
| C3 | Wat doen jullie als een criterium steeds afwijkt van onze beoordelaars? | Een herformulering van het criterium en daarna een nieuwe test |
| C4 | Hoe houden jullie beoordelaars onderling consistent? | Kalibratiesessies die de scorecard bijwerken |
| C5 | Hoe maakt een medewerker bezwaar tegen een score? | Een vastgelegd bezwaarproces |
Blok D: Kanalen en integraties (5 vragen)
| # | Vraag | Wat een goed antwoord laat zien |
|---|---|---|
| D1 | Welke van onze kanalen kunnen op één scorecard worden beoordeeld: telefoon, chat, e-mail, messaging? | Eén standaard over alle kanalen |
| D2 | Hoe koppelen jullie met onze helpdesk, en is dat een native integratie? | Native integraties bij naam genoemd voor jouw systemen |
| D3 | Hoe gaan jullie om met gesprekken: import van opnames, transcriptie, talen? | Een duidelijke route voor telefonie, niet ‘op de roadmap’ |
| D4 | Hoe komen gesprekken uit een eigen systeem bij jullie binnen? | Een connector, API of bestandsimport, met de formaten |
| D5 | Hoe komen scores en data in onze BI-tools? | Geplande exports in standaardformaten |
Blok E: Coaching en rapportage (4 vragen)
| # | Vraag | Wat een goed antwoord laat zien |
|---|---|---|
| E1 | Hoe worden kwaliteitsresultaten coaching voor een medewerker? | Feedback gekoppeld aan de gesprekken waar die uit komt |
| E2 | Wat ziet een teamleider zonder een analist te vragen? | Dashboards per medewerker, team en criterium |
| E3 | Hoe brengen jullie trends en oorzaken over alle gesprekken in beeld? | Analyse op volledige dekking, niet op een steekproef |
| E4 | Hoe verdelen jullie reviewwerk over beoordelaars? | Toewijzingen die het werk gelijk verdelen |
Blok F: AI-agents en bots (3 vragen)
| # | Vraag | Wat een goed antwoord laat zien |
|---|---|---|
| F1 | Kunnen jullie gesprekken van onze AI-agent op dezelfde scorecard beoordelen als die van menselijke medewerkers? | Eén standaard voor mensen en AI-agents |
| F2 | Hoe beoordelen jullie de overdracht van de AI-agent naar een mens? | Controles aan beide kanten van de overdracht |
| F3 | Hoe komen bevindingen terug in de content of regels van de bot? | Een route van fout naar oplossing |
Beantwoorden AI-agents al een deel van je wachtrij, dan zet onze gids over kwaliteitscontrole van AI-agents op een rij wat je moet beoordelen.
Blok G: Beveiliging, privacy en juridisch (5 vragen)
| # | Vraag | Wat een goed antwoord laat zien |
|---|---|---|
| G1 | Welke onafhankelijke audits en certificeringen hebben jullie, en mogen we de rapporten zien? | Actuele rapporten, beschikbaar onder NDA |
| G2 | Waar worden onze gegevens opgeslagen en verwerkt, en door welke subverwerkers? | Een gepubliceerde lijst van subverwerkers met locaties |
| G3 | Gebruiken jullie onze gegevens om AI-modellen te trainen of te finetunen? | Een helder schriftelijk antwoord, in het contract |
| G4 | Wat gebeurt er met onze gegevens aan het einde van het contract? | Een teruggavetermijn en een verwijderregel |
| G5 | Tekenen jullie een verwerkersovereenkomst, en wat dekt die? | Een overeenkomst die ook de AI-functies dekt |
Blok H: Implementatie en support (4 vragen)
| # | Vraag | Wat een goed antwoord laat zien |
|---|---|---|
| H1 | Wat houdt de onboarding in, en wie doet wat? | Een plan met jouw taken en die van de leverancier |
| H2 | Hoe lang duurt het voordat de eerste gesprekken beoordeeld zijn? | Een realistische termijn en waar die van afhangt |
| H3 | Wie begeleidt ons na livegang, en onder welke voorwaarden? | Een vaste contactpersoon en supportvoorwaarden |
| H4 | Hoe helpen jullie beoordelaars en medewerkers de tool te gaan gebruiken? | Training en een uitrolplan, zie ons uitrolplan voor een QA-tool (in het Engels) |
Blok I: Commerciële voorwaarden (3 vragen)
| # | Vraag | Wat een goed antwoord laat zien |
|---|---|---|
| I1 | Wat is de prijseenheid (licentie, beoordelaar, gesprek, minuut) en wie telt als licentie? | Een definitie die je op je organigram kunt toepassen |
| I2 | Wat zit er in elk abonnement en wat is een add-on? | Een tabel, geen bandbreedte |
| I3 | Wat verandert er bij verlenging of als ons team groeit? | Schriftelijke voorwaarden voor verlenging en groei |
Zo scoor je de antwoorden van leveranciers
Geef elk antwoord 0 tot 3 punten volgens geschreven definities, neem per blok het gemiddelde en pas dan de weging toe. Beoordeel beveiliging en datavoorwaarden eerst als poort, zodat een hoge functiescore een leverancier die daar faalt niet redt.
| Score | Definitie |
|---|---|
| 0 | Niet aangeboden of geen antwoord |
| 1 | Aangeboden met grote beperkingen, of alleen beloofd voor later |
| 2 | Aangeboden en voldoet aan de eis, bewijs deels getoond |
| 3 | Voldoet aan de eis, met bewijs getoond in het antwoord of de demo |
Hieronder een weging voor een contactcenter waar volledige en eerlijke dekking het hoofddoel is. Pas de weging aan je prioriteiten aan voordat de antwoorden binnenkomen, en verander haar daarna niet meer.
| Blok | Weging | Poort |
|---|---|---|
| A. Dekking en beoordeling | 25 | |
| B. De scorecard en haar standaard | 15 | |
| C. Nauwkeurigheid en validatie | 15 | |
| D. Kanalen en integraties | 15 | Knock-out als je helpdesk of hoofdkanaal niet wordt ondersteund |
| E. Coaching en rapportage | 10 | |
| F. AI-agents en bots | 5 | |
| G. Beveiliging, privacy en juridisch | Poort | Knock-out als een van G1 tot en met G5 een 0 krijgt |
| H. Implementatie en support | 10 | |
| I. Commerciële voorwaarden | 5 | |
| Totaal | 100 |
De gewogen score van een leverancier is de som per blok van weging maal gemiddelde score, gedeeld door 3. Een leverancier die overal 3 scoort, komt op 100. Laat minstens twee mensen onafhankelijk scoren en vergelijk: waar ze op een vraag meer dan één punt verschillen, was de vraag of het antwoord onduidelijk.
Een uitgewerkt scorevoorbeeld
Dit is een illustratief voorbeeld met drie verzonnen leveranciers, geen echte uitslag. Het laat zien hoe het scoreblad zich gedraagt als de totalen dicht bij elkaar liggen en als een knock-out geldt.
| Blok (weging) | Leverancier A | Leverancier B | Leverancier C |
|---|---|---|---|
| A. Dekking en beoordeling (25) | 3 | 2 | 3 |
| B. Scorecard (15) | 2 | 3 | 3 |
| C. Nauwkeurigheid en validatie (15) | 3 | 2 | 1 |
| D. Kanalen en integraties (15) | 2 | 3 | 2 |
| E. Coaching en rapportage (10) | 2 | 2 | 2 |
| F. AI-agents (5) | 1 | 3 | 2 |
| G. Beveiligingspoort | Door | Door | Niet door (G3 scoort 0) |
| H. Implementatie (10) | 2 | 3 | 3 |
| I. Commerciële voorwaarden (5) | 2 | 2 | 3 |
| Gewogen score | 78,3 | 81,7 | Uitgesloten (zou 80,0 zijn) |
Leverancier A: (25×3 + 15×2 + 15×3 + 15×2 + 10×2 + 5×1 + 10×2 + 5×2) ÷ 3 = 235 ÷ 3 = 78,3.
Leverancier B: (25×2 + 15×3 + 15×2 + 15×3 + 10×2 + 5×3 + 10×3 + 5×2) ÷ 3 = 245 ÷ 3 = 81,7.
Leverancier C zou op 80,0 zijn uitgekomen, maar kon niet schriftelijk bevestigen of hij modellen traint op jouw gegevens, dus de poort sluit hem uit.
De les zit in het verschil tussen A en B: 3,4 punten valt binnen de ruis van twee mensen die 40 antwoorden scoren.
Spreek vooraf een beslisregel af, bijvoorbeeld ‘bij minder dan 5 punten verschil wint de hoogste score op het zwaarst wegende blok’. Hier is dat leverancier A, met een 3 op dekking tegen een 2 voor B. Bevestig dat daarna met een gescripte demo rond je zwaarst wegende vragen.
Houd een gescripte demo en check daarna referenties
Een gescripte demo laat elke finalist live je zwaarst wegende vragen beantwoorden, in dezelfde volgorde, zodat je producten vergelijkt en geen presentatoren. Stuur het script een week vooraf en scoor de demo op dezelfde schaal van 0 tot 3.
Een goed script vraagt elke leverancier te laten zien, niet te vertellen:
- een beoordeeld gesprek op elk van je kanalen, met het bewijs achter elk criterium
- een beoordelaar die een automatische score aanpast, en waar die wijziging wordt vastgelegd
- je eigen scorecard, of een vergelijkbare kopie, ingericht met je weging en een kritiek criterium
- het dashboard dat een teamleider op maandagochtend opent
- hoe een gewijzigd criterium doorwerkt in toekomstige scores
Vraag na de demo om een of twee referenties van teams met een vergelijkbare omvang en kanaalmix. Vraag wat langer duurde dan verwacht, niet of ze tevreden zijn.
Plan na je keuze hoe je de scores in de eerste weken op je eigen gesprekken controleert. Ons protocol van een week om AI-beoordeling te valideren (in het Engels) geeft je de methode.
Fouten die antwoorden onvergelijkbaar maken
De meeste RFP’s mislukken omdat de vragen uitnodigen tot marketingantwoorden en de scoring pas na de antwoorden wordt bepaald. Vijf fouten verklaren bijna alles.
| Fout | Wat er gebeurt | Oplossing |
|---|---|---|
| Ja/nee-vragen | Elke leverancier antwoordt ja | Vraag ‘hoe’ en ‘laat zien’ |
| Geen weging vóór de antwoorden | De favoriet wint achteraf | Leg de weging vooraf vast |
| Prijs gescoord als functie | Een goedkope tool zonder dekking wint | Houd commerciële voorwaarden op 5 tot 10 punten en vergelijk kosten apart |
| Tweehonderd vragen | Sales antwoordt uit een bibliotheek | Blijf bij ongeveer 40 vragen die ertoe doen |
| Geen knock-outcriteria | Een leverancier die je verwerkersovereenkomst niet kan tekenen haalt de finale | Schrijf vijf knock-outs of minder op |
Kosten verdienen een eigen model: licentie, onboarding, tijd van beoordelaars en de tijd tot volledige dekking. Onze gids over de ROI van Auto QA (in het Engels) laat zien hoe je dat opbouwt.
Zo start je deze week je RFP voor kwaliteitssoftware
Begin met het invullen van de contexttabel en je knock-outcriteria, en kopieer dan de 40 vragen en het scoreblad naar je eigen document. Spreek de weging in één overleg af met IT, juridisch, inkoop en je kwaliteitsmanager, voordat je iets verstuurt.
Staat Kaizo op je lijst, dan zijn dit de basis van onze antwoorden. AutoPilot beoordeelt 100 % van je gesprekken volgens je rubric zodra ze zijn opgelost, en Auto QA bereidt scores en feedback voor die een beoordelaar aanpast en goedkeurt.
Je kunt de AI vóór livegang testen tegen je historische beoordelingen, en ons Trust Center noemt het SOC 2 Type II-rapport, het ISO 27001-certificaat en de verwerkersovereenkomst, beschikbaar op aanvraag. De prijs is per licentie, zoals op onze prijspagina staat.
Zie in een live demo hoe Kaizo deze vragen beantwoordt, met realistische voorbeelddata en je RFP bij de hand. Boek een afspraak.
Veelgestelde vragen
Hoe schrijf je een RFP voor contactcentersoftware?
Beschrijf eerst je operatie: licenties, volumes, kanalen, helpdesk en huidig proces. Zet daarna je must-haves en knock-outcriteria op een rij, schrijf vragen die om bewijs vragen en leg scoremethode en weging vast voordat je verstuurt. Geef een planning voor vragen, antwoorden, demo’s en besluit, en wijs één contactpersoon aan.
Wat is het verschil tussen een RFI en een RFP?
Een RFI (request for information) is een kort, vroeg document om de markt te leren kennen en een shortlist te maken. Een RFP (request for proposal) gaat naar die shortlist en vraagt om een concrete oplossing, met antwoorden die je scoort en een prijs. Veel kopers van kwaliteitssoftware slaan de RFI over en sturen een RFP naar drie tot vijf leveranciers.
Naar hoeveel leveranciers stuur je een RFP?
Drie tot vijf is meestal genoeg. Minder laat weinig te vergelijken; meer levert scorewerk op dat de uitkomst zelden verandert. Maak de lijst eerst korter met onze vergelijking van kwaliteitssoftware of een kort gesprek met elke leverancier, en laat iedereen vallen die in dat gesprek op een knock-out sneuvelt.
Hoe lang duurt een RFP voor kwaliteitssoftware?
Voor de meeste contactcenters is vier tot acht weken van versturen tot besluit realistisch: ongeveer twee weken voor antwoorden, een tot twee weken voor scoring en demo’s, en de rest voor referenties, beveiligingsreview en contract. Beveiligings- en juridische reviews duren vaak het langst, dus start ze parallel aan de demo’s.
Moet de prijs meetellen in de RFP-score?
Vraag de prijs in de RFP, maar laat die licht meewegen in de functiescore, ongeveer 5 tot 10 punten. Vergelijk de totale kosten apart, inclusief tijd van beoordelaars, onboarding en groeivoorwaarden. Een goedkopere tool die minder gesprekken beoordeelt of meer handmatige review vraagt, kan over de looptijd van het contract duurder uitvallen.
