Vraag een leverancier hoe lang de implementatie duurt en je krijgt een bandbreedte. Vraag een enterprise-inkoper waarvoor budget is gereserveerd en je hoort vaak 12 tot 18 maanden. Beide getallen zijn oprecht, maar ze meten iets anders. De leverancier telt de configuratie. Jij telt de tijd tussen de handtekening en het eerste autonoom opgeloste ticket.
Het grotere getal verdient een kritische blik, want het is geen eigenschap van de technologie. De doorlooptijd van 12 tot 18 maanden waar de meeste enterprises van uitgaan, is een bijproduct van het inkoopproces, geen productvereiste. Die doorlooptijd ontstaat omdat 3 werkstromen na elkaar worden doorlopen in plaats van tegelijk.
De 3 vertragende factoren, en waarom ze na elkaar lopen
Eerst komt de leveranciersselectie. Er worden eisen opgesteld en demo's ingepland, er ontstaat een shortlist en er valt een besluit. Pas dan begint de security review, want niemand wil compliance doorlopen voor 5 leveranciers als er 4 gaan afvallen. Daarna start de integratieplanning, omdat het als verspilling voelt om integraties te scopen voor een leverancier die je nog niet hebt gekozen.
Op papier is dat allemaal heel logisch. Samen leveren ze een inefficiënte tijdlijn op waarin niets overlapt. Ze parallel uitvoeren voelt ongemakkelijk, want dan steek je security review-werk in leveranciers die niet winnen en scope je integraties die misschien worden weggegooid. Toch is het de grootste hefboom die je hebt op de implementatietijd, en het weggegooide werk is goedkoop vergeleken met een kwartaal aan gemiste waarde uit nieuwe mogelijkheden.
Wat er gebeurt als de tijdlijn uitloopt
Gartner verwacht dat eind 2027 meer dan 40% van de agentic AI-projecten is stopgezet, vanwege oplopende kosten, onduidelijke bedrijfswaarde en ontoereikende risicobeheersing. In dezelfde analyse merkt Gartner op dat het integreren van agents in legacysystemen technisch vaak complex is, workflows verstoort en dure aanpassingen vereist.
Die 2 bevindingen beschrijven hetzelfde faalpatroon. Projecten worden zelden stopgezet omdat een model in tests tegenviel. Ze worden stopgezet omdat het verbindende werk bleef uitdijen terwijl de business case wachtte op resultaten die maar niet kwamen. Een lange tijdlijn is niet alleen traag: het is precies de situatie waarin stopzetten de rationele keuze wordt.
Waar de architectuur elke fase verlengt
Bij een migratiemodel worden artikelen geëxporteerd en opnieuw opgemaakt, wordt de taxonomie opnieuw opgebouwd, wordt de tickethistorie geïmporteerd, worden rechten opnieuw gemapt en wordt identiteit opnieuw ingericht, nog voordat de configuratie echt begint. Er is ook een kostenpost die niemand noemt. Tijdens de migratie is je kennisbank feitelijk in aanbouw, dus het team dat hem beheert stopt met bijwerken of werkt op 2 plekken bij. Het product krijgt updates, beleid verandert, en de gemigreerde kopie klopt niet meer, op een manier die niemand opmerkt tot een klant het oude antwoord krijgt.
Bij een overlaymodel maakt de agent verbinding met de systemen die je al gebruikt, leest hij kennis waar die staat en handelt hij via de tools die je team al gebruikt. Er verhuist niets, dus het integratietraject wordt korter en de bevriezing verdwijnt. Dezelfde logica geldt voor voice, waar voice-to-voice agents aansluiten op de telefonie die je al hebt, in plaats van dat je eerst je telefoniesysteem moet migreren.
De afhankelijkheidsketen die te laat wordt gescoped
Kennis is het zichtbare deel. In de rest van de keten zit het echte integratiewerk, en daarom is vroeg beginnen belangrijker dan snel afronden.
- Identiteit. De agent moet weten met wie hij praat. Daarmee komt hij in je single sign-on en klantauthenticatie terecht, en dus in de wachtrij van je securityteam.
- Rechten. Een agent die problemen oplost, moet mogen handelen. Iemand bepaalt welke acties, voor welke accounttypen, tot welke drempels, en waarvoor een mens nodig is. Dat is een beleidsvraagstuk waarvoor beslissers nodig zijn, geen engineeringticket.
- Downstream systemen. Een terugbetaling raakt de facturatie. Een adreswijziging raakt het orderbeheer. Elke koppeling is op zich eenvoudig, en elke koppeling heeft een eigenaar die niet in het oorspronkelijke projectplan stond.
Niets hiervan verdwijnt, welke architectuur je ook kiest. De vraag is of je er in week 1 mee aan de slag gaat of pas nadat een dataproject is afgerond.
Hoe de verkorte versie eruitziet
K1x ging live en haalde binnen de eerste week 80% autonome resolutie. Geen pilot in week 1 en productie later. Resolutie in week 1. Papaya Pay bereikte 90% autonome resolutie in 3 weken. Over alle enterprise-implementaties heen duurt het gemiddeld 4 tot 6 weken van contract tot productie.
Die doorlooptijden zijn niet te danken aan uitzonderlijk goed voorbereide klanten. Ze zijn het resultaat als er geen migratie op het kritieke pad ligt en de 3 vertragende factoren overlappen in plaats van op elkaar te wachten.
Vragen die de echte tijdlijn blootleggen
- Leest de agent onze kennis op de plek waar die staat, of heeft hij een kopie nodig?
- Als ons team een artikel bijwerkt, hoe lang duurt het dan voordat het antwoord van de agent verandert?
- Wat moet er verhuizen voordat het eerste ticket autonoom wordt opgelost?
- Welke integraties zijn nu al native, en welke worden tijdens de onboarding gebouwd?
- Wat is de snelste tijd waarin een klant ooit in productie ging, en waardoor ging het zo snel?
Druk vooral door op die laatste. Snelle implementaties hebben meestal een gemeenschappelijke oorzaak, en een leverancier die die niet kan benoemen, had misschien eerder geluk dan de juiste architectuur.
Waarom de tijdlijn de strategie is
Met een implementatie die binnen weken landt, meet je de resolutiegraad op echt volume terwijl het budgetgesprek nog loopt. Een implementatie die kwartalen duurt, levert je eerste echte data pas op na het besluit dat ervan afhing. Juist die volgorde, meer dan welke modelbenchmark ook, bepaalt doorgaans welke programma's worden verlengd en welke worden afgeschreven.
The 90-Day Pilot Scope beschrijft een referentiescope om resolutie aan te tonen vóór een brede uitrol, gebaseerd op het hoofdstuk Deployment Paradox uit het State of AI in CX 2026-rapport .
Zie het op je eigen gesprekken.
Vraag een gratis demo op maat aan.
