Meldingen als tickets met status, bijlagen en opvolging, in een klantomgeving. Voor onderhoud, ICT en beheer. Bewezen in de bouw en op ons eigen platform.
Een ticketsysteem zet elke melding van een klant om in een ticket met status, bijlagen en historie, zichtbaar in een klantomgeving waar je klant de voortgang zelf volgt. EIGHTY8 bouwde zo'n ticketomgeving voor een onderhoudsbedrijf en draait er zelf ook op. Elke vraag loopt er als ticket door.
Meldingen van klanten komen binnen als mail, appje, telefoongesprek of formulier. En verdwijnen daarna in een tussenwereld. Niemand weet precies wie welke melding oppakt, welke status hij heeft en of er al iets is gedaan. De klant belt of mailt na een paar dagen, juist omdat hij niets kan zien; de vraag zelf is dan al extra werk geworden.
Bijlagen maken het erger: de foto van de schade staat in de mail van vorige week, de specificatie in de map van een collega, en bij overdracht (vakantie, wisseling van functionaris) valt de historie weg. Wat overblijft is een team dat het goede bedoelt en een klant die het slechte vermoedt. Het tekort is geen inzet maar zichtbaarheid, en zichtbaarheid is precies wat een ticketstructuur geeft.
De klant maakt zijn melding in de klantomgeving: wat hij ziet, wat er gebeurd is en (waar het helpt) een foto of bestand erbij. De melding wordt een ticket met een status die jij beheert: nieuw, in behandeling, wacht op informatie, afgerond. Met jouw statusnamen en jouw regels voor wie welke stap zet. Elke reactie, wijziging en bijlage blijft bij het ticket staan, in de volgorde waarin het gebeurde.
Aan jouw kant ziet het team dezelfde tickets met de historie erbij: wie oppakt wat, wat al gevraagd is en waar het wacht. De klant ziet de voortgang in zijn omgeving en hoeft niet te bellen om te weten dat er iets gebeurt. Nieuwe tickets en reacties komen bij je team terecht via het kanaal dat jullie gebruiken, zodat een melding nooit stil in een systeem blijft hangen.
Eerlijk over de grens: een ticketstructuur verplicht niemand tot snelheid. Hoe snel jullie reageren en afronden, staat in jullie voorwaarden. De software houdt het bij, ze bewaakt geen belofte die jij niet wilt maken. Zo draait het bij een onderhoudsbedrijf waar klanten tickets, projecten en onderhoud in hun eigen area zien, en op ons eigen platform: elke vraag van elke klant hier loopt als ticket door, inclusief bijlagen die er vóór deze manier van werken verloren gingen.
Een servicedesk wordt gedragen door drie keuzes: welke soorten meldingen er zijn, wie ze oppakt en wat de klant mag zien. Deze vier bouwstenen vertalen die keuzes.
Het werkt voor wie structureel meldingen van klanten afhandelt: onderhouds- en installatiebedrijven, ICT en beheer, vastgoedbeheer, productbedrijven met service na levering, elke organisatie waar een vraag meer dan één bericht kost om op te lossen.
Het werkt niet voor wie een handvol vragen per maand krijgt. Een nette inbox volstaat dan, en een systeem zou alleen extra kliks betekenen. Ook niet als de afhandeling altijd ter plekke gebeurt en er geen verslag overblijft om bij te houden. En niet als je het team dwingt een omgeving te gebruiken die ze vermijden: begin dan met de kant van het team, want een servicedesk die intern stoffig wordt, wordt aan de klantkant nooit warm.
Wat dit vraagt hangt af van het aantal soorten meldingen, welke rechten klanten krijgen en of het ticketsysteem onderdeel is van een bredere klantomgeving of los staat. We brengen dat samen in een korte verkenning, zetten de aannames in een voorstel en rekenen af op wat er gebouwd is. Een servicedesk groeit bovendien goed in stappen: eerst tickets en status, daarna bijlagen, rapportages of een bredere klantarea.
Een ticket heeft een status, een eigenaar en een historie die aan de zaak zelf hangt; een mail heeft een inbox die verhuist met wie hem toevallig opent. In een ticketomgeving is altijd te zien wat de stand is, wat er gevraagd is en wanneer. Door iedereen die er rechten op heeft, zonder te scrollen door berichten. De klant ziet bovendien dezelfde status, waardoor de klassieke vraag hoe het ervoor staat overbodig wordt.
Ja, en dat is vaak het verschil tussen een goede en een slechte eerste diagnose: de foto van de schade hoort bij de melding, niet in een aparte mail. Bestanden worden bij het ticket bewaard en blijven beschikbaar zolang het ticket bestaat, ook na afronding. De toegestane formats en de maximale grootte stel je zelf in; grotere bestanden zoals video's zijn mogelijk met de uploadaanpak die we standaard bouwen.
Via het kanaal dat je team al gebruikt: een melding per mail of in de eigen omgeving, met het ticket ernaast zodat iemand direct kan reageren. Je bepaalt welke soorten meldingen naar welke collega of groep gaan. Is een ticket eenmaal onder de aandacht, dan volgen verdere stappen binnen het systeem. Zodat het gesprek en de historie bij elkaar blijven in plaats van terug te vallen naar losse mails.
Ja, en dat is een logische volgorde. Tickets zijn vaak het onderdeel met de meeste directe winst, waarna documenten, projecten en facturatie in dezelfde omgeving kunnen bijkomen. We bouwen de basis zo dat uitbreiden geen herbouw betekent. Wil je andersom beginnen (portaal eerst, tickets later) dan kan dat ook, mits de klantomgeving vanaf het begin op meerdere onderdelen ingericht wordt.
EIGHTY8