Intake automatiseren: aanvragen komen gestructureerd binnen, worden geprioriteerd en landen in je systeem. Van rijschool tot spoeddienst.
Intake-automatisering zorgt dat een aanvraag die binnenkomt (formulier, mail, telefoonnotitie) direct gestructureerd en geprioriteerd in je systeem ligt vóórdat een mens hem leest. EIGHTY8 bouwt zulke intakes voor spoeddiensten, rijscholen en uitzendbureaus, en gebruikt er zelf één voor elke nieuwe aanvraag.
Aanvragen komen binnen via vijf kanalen en geen één van ze levert ze in dezelfde vorm. Het webformulier geeft halve zinnen, de mail geeft bijlagen zonder onderwerp, een telefoongesprek geeft een medewerker die snel tikt wat de beller zegt. Iemand moet al die vormen omzetten naar het systeem waar het werk echt loopt: de planning, het klantendossier, de ticketlijst.
Intussen staat de druk te tikken. Een spoedmelding ligt tussen nieuwsbrieven en een aanvraag zonder postcode moet eerst teruggebeld worden voordat er iets mee te beginnen valt. Onderweg verliezen twee dingen het: urgentie (niet alles dat als spoed binnenkomt, is het, en niet alles dat het is, valt op) en volledigheid, want een intake die halverwege afgebroken wordt komt nooit terug.
De intake-workflow leest elke aanvraag op het moment dat hij binnenkomt en doet drie dingen vóór een mens hem ziet. Hij structureert: vrije tekst, bijlagen en formulier worden omgezet naar de velden waar jouw systeem op rekent. Wie, wat, waar, wanneer. Hij controleert: ontbreekt er iets dat noodzakelijk is, dan stelt de intake de vraag terug aan de aanvrager in jouw woorden, in plaats van het halfvolle formulier door te sturen. En hij prioriteert: volgens de spoedregels die jij bepaalt, krijgt elke aanvraag een plek in de rij.
Waar een model nuttig is, is bij het lezen: een melding in gebroken Nederlands, een foto van een schade, een omschrijving die eigenlijk twee problemen bevat. De beslissing over wat urgent is, laat je aan regels over. Daarin is een systeem betrouwbaarder dan een mens onder tijdsdruk. De mens blijft aan het einde van de lijn: hij ziet een gesorteerde, geprioriteerde intake en besteedt zijn tijd aan het echte contact, niet aan het overtypen.
Zo draait het bij een spoed-app die meldingen per prioriteit uitrolt naar beschikbare mensen, bij een rijschool waar lesaanvragen meteen compleet in de planning landen en bij uitzendbureaus waar kandidaat- en klantaanvragen gestructureerd binnenkomen. Onze eigen intake doet hetzelfde voor elke nieuwe opdracht die hier binnenkomt.
Een intake kan alleen zoveel structuur brengen als er aan de achterkant een plek is waar die structuur terechtkomt. De vier bouwstenen hieronder komen in de discovery aan bod.
Het werkt waar aanvragen frequent zijn en gestructureerd verwerkbaar: spoed- en storingsdiensten, rijscholen, uitzendbureaus, installateurs, praktijken met doorverwijzingen, elke organisatie waar de intake vóór het werk komt en het werk snel moet beginnen. Hoe hoger het tempo, hoe groter het verschil tussen een intake die iemand overtypet en één die vanzelf ligt.
Het werkt niet voor wie zo weinig aanvragen krijgt dat ordenen geen werk is. Een inbox volstaat dan, en het zou onnodige kosten betekenen. En het werkt niet als er nog geen systeem bestaat waarin de intake kan landen: eerst een plek waar het werk loopt, dan de workflow die erheen leidt. Heb je beide tegelijk nodig, dan beginnen we liever bij het systeem.
Elk traject wordt vooraf ingeschat op zijn eigen omvang: het aantal kanalen, de hoeveelheid velden, de spoedregels en het systeem waarin de intake uitmondt bepalen samen het werk. Je krijgt vooraf een voorstel met die aannames op papier en rekent af op nacalculatie van wat er gebouwd is. Uitbreidingen (een nieuw kanaal, een extra prioriteitsregel) worden op dezelfde manier voorgesteld voordat ze gebouwd worden.
Omdat jij dat in regels vastlegt, niet omdat een model het gokt. Een storingsmelding met water op de vloer is een andere regel dan een vraag over een factuur, en jouw spoedcriterium mag per klanttype verschillen. De intake past die regels consequent toe en markeert wat hij niet zeker weet. De definitieve inschatting blijft bij jouw team. Maar die begint bij een gesorteerde rij in plaats van bij een postvak.
Die gaan niet halfverwerkt het systeem in. De intake herkent welke velden noodzakelijk zijn voor jouw werk (een adres, een foto, een keuze) en vraagt precies dat terug aan de aanvrager, in een korte mail met jouw formulering. Pas als de intake compleet is, landt hij bij je team. Zo voorkom je de terugbelronde die kostbaarder is dan de aanvraag zelf.
Ja, en dat is vaak het mooiste van twee werelden. Bellen blijft mogelijk voor wie dat nodig heeft; de intake vangt op wat digitaal binnenkomt en houdt de rij overzichtelijk. Sommige bedrijven laten bellers na het gesprek een korte bevestiging sturen die als intake dient, zodat zelfs het telefoongesprek in hetzelfde systeem eindigt en niets meer alleen in iemands geheugen bestaat.
Een intake verwerkt naam, adres en vaak gevoelige context. Daarom leggen we vooraf vast welke velden de workflow mag zien, waar ze bewaard worden en hoe lang. Velden die niet nodig zijn voor structurering hoeven geen model te passeren. Je houdt de beschikking over wie in jouw team de intake kan inzien, en elke stap die een aanvraag neemt is terug te volgen in het log.
EIGHTY8