Klantportaal vs traditionele helpdesk voor softwarebureaus

De drie modellen, eerlijk vergeleken

De eerlijke samenvatting: e-mail is het beste voor de klant en het slechtste voor jou, een portaal is het beste voor jou en vraagt iets meer van de klant, en een helpdesk op e-mail is een compromis dat prima werkt tot je betrouwbare toewijzing nodig hebt.

Wat een portaal je echt oplevert

Geen "professionele uitstraling". Vier concrete dingen.

Eén draad per stuk werk

Mailthreads splitsen. Iemand reageert op een ouder bericht, halverwege komt er een tweede persoon bij, en het gesprek valt uiteen in twee versies van de werkelijkheid. Een ticket heeft één draad, en daardoor staat de geschiedenis van een besluit op één plek als iemand een jaar later vraagt waarom het systeem zich zo gedraagt.

Intern en extern zijn verschillende objecten

In e-mail is het verschil tussen een interne notitie en een antwoord aan de klant de inhoud van het aan-veld. Dat is één fout verwijderd van een klant die de eerlijke mening van een engineer over zijn oude systeem leest. Op een ticket is een interne reactie een ander soort record en kan hij niet per ongeluk verstuurd worden.

Klanten beantwoorden hun eigen statusvraag

Een aanzienlijk deel van de supportmail is geen nieuwe informatie, maar "hoe staat het ermee?". Een portaal waarin de klant de status ziet, plus een wekelijkse samenvatting die hij ongevraagd krijgt, haalt het grootste deel van dat verkeer weg. Het voorkomt ook dat het antwoord afhangt van wie van jouw mensen hij toevallig mailde.

De scheiding is structureel

Met meerdere klanten in één systeem kan afscherming geen filter zijn dat iemand toevallig toepaste. In Suporta heeft elke organisatie een eigen database en subdomein, zijn gebruikers toegewezen aan bedrijven, en zien klantgebruikers alleen de tickets van hun eigen bedrijf, afgedwongen op de server en niet in de interface.

De twee bezwaren die je echt gaat horen

"Onze klanten loggen toch nooit in." Sommigen niet, en dat is prima: houd e-mail als ingang en laat die tickets aanmaken, zodat het portaal de plek is waar het werk wordt gevolgd in plaats van de enige deur. Wie wél inlogt, is meestal degene die het meest om status geeft: de projectleider aan klantzijde die intern moet rapporteren.

"Het voelt bureaucratisch voor een kleine klant." Dat klopt als het portaal zwaar is. Houd het klantgedeelte bij wat hij nodig heeft: indienen, status zien, reageren, en een lijst met wat openstaat. De rest is jouw kant van het product, niet de zijne.

Bepaal wat klanten wel en niet zien

Een portaal is eerst een zichtbaarheidsbesluit en pas daarna een softwarebesluit. Ga je de mist in, in welke richting dan ook, dan creëer je werk: te weinig en ze blijven mailen, te veel en ze gaan je sprint managen.

Klanten naar een portaal brengen zonder ze te irriteren

1. 1Begin bij de klant die het vaakst achter je aan zit. Die haalt de meeste waarde uit zelf status opzoeken, dus hij went het snelst en klaagt het minst.
2. 2Zet e-mail niet uit. Laat die binnenkomen in hetzelfde systeem. Een deur die je sluit, is een klant die je accountmanager belt.
3. 3Vul het met echte openstaande tickets voordat je iemand uitnodigt. Een leeg portaal op dag één oogt als extra werk voor niets.
4. 4Stuur de wekelijkse samenvatting vanaf week één. Die laat de waarde zien voordat er ook maar iemand heeft ingelogd.
5. 5Geef precies één persoon aan klantzijde een rondleiding van tien minuten. Die leert het zijn collega's, en jij hoort welk deel van je interface onduidelijk is.

De maatstaf voor succes is niet het aantal logins. Het zijn minder "hoe staat het ermee"-mails en minder overleggen die alleen bestaan om status door te geven. Dalen die allebei, dan werkt het portaal, of de klant er nu dagelijks komt of niet.