Chat tussen klant, medewerker en kantoor ín het portaal, met de context van de opdracht erbij. Bewezen in een staffing-portaal, op nacalculatie.
In-app chat betekent dat klant, medewerker en kantoor binnen het portaal met elkaar praten. Met de opdracht, de documenten en de status er direct naast, in plaats van losse berichtjes eromheen. EIGHTY8 bouwt de chat in je bestaande portaal, met een geschiedenis die bij de zaak hoort en niet bij iemands toestel.
Het contact loopt via privé-appjes, persoonlijke nummers en mailtjes die ergens anders leven dan het werk waar ze over gaan. Een vraag over deze opdracht belandt bij de medewerker die toevallig haar nummer heeft gedeeld; zodra zij vrij is of overstroomt, hangt de vraag vast en weet de klant niet wie hem nu moet berichten. Niemand vindt de draad terug: de opdracht staat in het portaal, de toelichting daarop staat in een appje op iemands toestel.
De vervelende gevolgen zijn niet eens luiheid maar structuur. Een collega die inspringt, ziet de opdracht maar niet het gesprek erover. Een klacht opnieuw uitzoeken betekent bellen en gokken. En privénummers maken van bedrijfscontact persoonlijk bezit. Wanneer iemand het bedrijf verlaat, vertrekt de lijn naar de klant met hem mee.
De chat staat ín het portaal, bij de opdracht of het dossier waar hij over gaat. De klant ziet zijn eigen gesprek met de context ernaast; de medewerker ziet hetzelfde gesprek met dezelfde context, ongeacht wie van het team hem oppakt. Bestanden en toelichtingen horen bij het bericht, en de geschiedenis blijft bij de zaak staan. Een nieuwe collega leest terug in plaats van opnieuw te bellen.
Een nieuw bericht is een melding voor de juiste kant, niet voor een privétoestel. Niemand deelt meer een persoonlijk nummer om bereikbaar te zijn, en het kantoor bepaalt wie een gesprek kan overnemen. Wil je de instroom aan de voorkant opvangen, dan kan een agent de eerste vraag beantwoorden uit de eigen kennis van het portaal en hem daarna aan een mens overgeven. Maar de ontwerpkeuze is per organisatie anders en hoort bij de discovery.
Eerlijk over wat chat níet is: geen spoedlijn. Een vraag die meteen beantwoord moet worden omdat er op dit moment iets misgaat, hoort bij een nummer dat daarvoor staat. In de discovery spreken we af welk type bericht waar hoort, want een kanaal zonder duidelijke rol wordt een stil kanaal dat niemand leest.
In-app chat is een laag op een bestaand portaal, geen op zichzelf staand product. Deze onderdelen bepalen het werk.
Het werkt voor organisaties met een portaal waar klanten regelmatig vragen over hebben: staffingorganisaties met flexkrachten en opdrachtgevers, dienstverleners met lopende opdrachten, platformen waar klant en kantoor elkaar periodiek spreken. Hoe meer het contact over een concrete opdracht gaat, hoe meer waarde de context ernaast levert.
Het werkt níet als er nog geen portaal is. Dan is het portaal de eerste stap en de chat de tweede, en beide tegelijk bouwen maakt het traject zwaarder dan nodig. Ook niet als je klanten liever bellen en de chat een tweede stil kanaal dreigt te worden; eerlijk gezegd gebeurt dat bij elke organisatie die een kanaal toevoegt zonder een rol ervoor te kiezen. En een chat ter vervanging van spoedlijnen is een verwachting die je achteraf niet meer terugneemt.
In het portaal van een staffingorganisatie praten flexkracht, bemiddelaar en opdrachtgever binnen dezelfde omgeving, met de opdracht waar het over gaat naast het gesprek. De publieke beschrijving staat op de casepagina. Wat je daar níet leest: gespreksvolumes, responstijden en welke teams het drukst zijn, want dat zijn cijfers van de organisatie zelf.
De prijs volgt uit het bestaande portaal, de rollen die meepraten en of een agent de eerste vragen opvangt. Chat is een laag over wat er al staat, dus de scope is meestal overzichtelijk; we zetten de aannames op papier en rekenen af op nacalculatie. Geen licentie per gebruiker en geen tarief per bericht. Het werk is bouwen, niet verhuren.
Dat gebeurt bij elke organisatie die een kanaal toevoegt zonder een rol ervoor te kiezen. Dus daar beginnen we mee. In de discovery leggen we per type bericht vast waar het hoort: lopende vragen over de opdracht in de chat, echte spoed telefonisch, formele stukken in het dossier. Wie die afspraak vastlegt en de meldingen goed inricht, ziet de chat worden waar de vragen terechtkomen die nu via privénummers lopen.
Alleen hun eigen dossier. Elke klant ziet zijn eigen gesprekken over zijn eigen opdrachten, niets van een andere klant of opdrachtgever. En binnen het kantoor bepalen de rollen wie welke gesprekken kan inzien of overnemen. Dat is hetzelfde onderscheid als in de rest van het portaal: de chat is geen openbare ruimte maar een gesprek per zaak, met dezelfde toegangsregels als de documenten ernaast.
Dat kan, als jullie dat willen. De agent antwoordt dan uit de kennis die al in het portaal staat (openingsuren, status, procedures) en geeft elke vraag die hij niet zeker weet met het volledige gesprek over aan een medewerker. Veel organisaties kiezen er bewust voor om dat niet te doen en alles bij mensen te laten; beide zijn goed, mits het een besluit is en geen gebrek aan besluit.
Dat hangt af van hoe het portaal is gebouwd, welke rollen meepraten en of er een agent aan de voorkant komt. Vaak is het een overzichtelijk traject, omdat de chat een laag over bestaande structuur is: rechten, opdrachten en meldingen zijn er al. We bekijken het in de discovery, leggen de scope vast en rekenen af op nacalculatie. Geen licentie per gebruiker, geen afrekening per bericht.
EIGHTY8