Ticketlevenscyclus en communicatie met klanten in de helpdesk

Introductie

In dit artikel bespreken we het ticketingproces, afhankelijk van de manier waarop een ticket wordt aangemaakt in de helpdesk en afhankelijk van de toegang van de klant tot uw systeem. Tips over waar je op moet letten bij verschillende ticketprocesconfiguraties vind je.

Dit artikel bevat tips en suggesties voor diverse configuraties, maar niet direct hoe de configuraties tot stand komen. Hier zijn de relevante artikelen:

Helpdeskdocumentatie

Subhoofdstuk Helpdeskgebruikers

Handleiding (workflow, meldingsinstellingen)

Drie belangrijke communicatieroutes

Te beginnen met een schema van de ticketlevenscyclus in eenvoudige situaties - wanneer het ticket van begin tot eind slechts één type stroom volgt.

E-mail
Volledige gebruiker in applicatie
Helpdeskgebruiker in applicatie

Aanmaak en verdere communicatie binnen een ticket

Het maken van tickets en verdere communicatie kunnen de bovenstaande benaderingen combineren.
Het is mogelijk om via e-mail een ticket aan te maken en deze vervolgens op te volgen in de applicatie (door volledige gebruiker of helpdeskgebruiker). Ook is het mogelijk om via het systeem een ticket aan te maken en dan alleen e-mails te volgen.

Voorbeeld 1

Tickets worden aangemaakt via e-mail - de klant stuurt een nieuwe e-mail naar het helpdeskadres.
De klant logt in op het systeem en kan daar het ticket zien, aangezien hij de ticketauteur is.
Klanten kunnen statussen en andere velden wijzigen en opmerkingen achterlaten, afhankelijk van hun machtigingen.

Voorbeeld 2

De klant logt in op het systeem en maakt een nieuw ticket aan.
Klant ontvangt updates via e-mail en bekijkt alleen deze updates en heeft geen behoefte meer om in te loggen op het systeem.

Voorbeeld 3

Klant maakt via het helpdeskportaal een ticket aan
Klant besluit alleen e-mails te willen volgen en logt niet meer in op de portal
De klant besluit vervolgens dat hij via het portaal wil volgen, logt I in en voert enkele antwoorden in via het portaal.

Voor het gemak van uw klanten kunt u beslissen op welke manieren u hen toestemming wilt geven om tickets aan te maken en/of bij te werken. Maar het allerbelangrijkste is dat u elke mogelijke situatie moet dekken, zodat tickets niet verloren gaan in een doodlopende straat. Workflow- en andere configuraties bieden alle benodigde opties.

Gebruikelijke problemen

Klant antwoordt op reguliere taakmeldingen, maar het antwoord wordt niet correct verwerkt.

Dit verhaal gaat over voorbeeld 2. Klanten denken dat ze een ticket via e-mail beantwoorden, maar de e-mail wordt niet gekoppeld aan het bestaande ticket en in plaats daarvan wordt een nieuw ticket aangemaakt, of de e-mail bereikt het systeem helemaal niet. Klant reageert op een melding of maakt per ongeluk een nieuwe e-mail aan.

De oorzaak: de instellingen voor e-mailmeldingen verwachten geen antwoorden op het meldingsadres.

Oplossing: Het antwoord van de klant moet naar een door de helpdesk opgegeven adres worden gestuurd en moet het ticketnummer bevatten. E-mailadres voor meldingen (Beheer >> Instellingen >> E-mailmeldingen >> E-mailadres voor meldingen (VAN)) kan hetzelfde zijn als een e-mailadres voor de helpdesk om eventuele antwoorden van klanten op te vangen en deze te koppelen aan het ticket van waaruit de melding in eerste instantie is verzonden.

Een andere optie is om reguliere e-mailmeldingen voor de klantgebruikers eenvoudigweg uit te schakelen. De enige e-mails van tickets die ze zouden ontvangen, zouden actief door de operators worden verzonden via e-mailsjablonen voor de helpdesk.

Belangrijkste conclusie: uw klanten zullen van nature in de verleiding komen om te reageren op e-mailberichten die zij ontvangen. Zorg ervoor dat ze alleen berichten ontvangen waarop de antwoorden goed kunnen worden verwerkt.

Klant heeft het ticket gewijzigd naar de status "onjuist".

Dit komt vooral voor in situaties waarin de client een volledige gebruiker in de applicatie heeft (in plaats van een helpdeskgebruiker). Klant heeft mogelijk de mogelijkheid om veel velden te bewerken, inclusief status, en kan de betekenis van verschillende statussen verkeerd interpreteren. Of aan de andere kant verandert de status mogelijk niet, terwijl u verwacht dat deze wordt gewijzigd.

De oorzaak: De klant wordt verantwoordelijk gesteld voor het instellen van de juiste status.

Oplossing: Dit is een duidelijk antipatroon; de cliënt hoeft geen regels voor taakstatussen te onthouden.

Eén oplossing is om het klantaccount om te zetten naar helpdeskgebruikers in plaats van volledige gebruikers. Helpdeskgebruikers kunnen tickets aanmaken en opmerkingen in bestaande tickets invoeren. Statuswijzigingen zijn gebaseerd op helpdeskconfiguraties, dus er is geen kans dat de klant een correct proces "verbreekt". De ticketupdates van helpdeskgebruikers zijn praktisch ontworpen om de logica en instellingen van de e-mailcommunicatie van de helpdesk te volgen. Het enige verschil is dat de gebruiker daadwerkelijk een fysieke vorm van het ticket kan zien en ermee kan werken.

Als u de volledige gebruikers voor uw klanten wilt behouden, raden wij u aan om eventuele statuswijzigingen (of andere veldwijzigingen) volledig uit te schakelen, waardoor sommige van uw interne processen kapot kunnen gaan. Gebruik andere manieren om tickets bij te houden die moeten worden bijgewerkt, bijvoorbeeld per veld Taak laatst bijgewerkt (datum laatste update), Laatst bijgewerkt door (wie heeft de laatste update gemaakt) kunt u de laatste opmerking op een ticket in de lijst weergeven, zodat duidelijk is welke klant de update heeft uitgevoerd.

Een iets ingewikkelder scenario komt uit Voorbeeld 1, waarin u ticketcommunicatie via e-mail toestaat, maar ook klanten toestaat in te loggen als volledige gebruiker. Hier leest u waar u op moet letten:

Statuswijziging nadat de klant per e-mail heeft gereageerd, wordt ingesteld in de algemene helpdeskinstellingen
Er is geen handhaving van de statuswijziging voor ingelogde gebruikers; er is altijd de optie om de status te behouden zoals deze is

In dit geval moet u ervoor zorgen dat uw wachtrijen voor antwoorden beide soorten situaties bevatten, bijgewerkt via e-mail (bijvoorbeeld filteren op een specifieke status), en tickets die zijn bijgewerkt door klanten vanuit de applicatie (bijvoorbeeld ticketlijst met kolom Laatste opmerking).

Belangrijkste conclusie: klanten moeten zich nooit zorgen maken over uw interne processen, ze hebben alleen een plek nodig om hun problemen voor te leggen en met u te communiceren, de processen zijn aan u en de applicatie heeft verschillende opties om deze strak te regelen.

Een combinatie van volledige gebruikers en helpdeskgebruikers

Dit is slechts een krachtige waarschuwing om geen oplossingen te combineren die nooit bedoeld waren om gecombineerd te worden. U kunt zelf beslissen of u er gebruik van wilt maken

Helpdeskgebruikers - gratis, met hardgecodeerde beperkte toegang, of
Volledige gebruikers - reguliere gelicentieerde gebruikers, waarbij u bepaalt waartoe zij toegang hebben

, maar u mag ze niet tegelijkertijd gebruiken, vooral niet voor dezelfde clients. Technisch gezien zijn volledige gebruikers en helpdeskgebruikers op geen enkele manier met elkaar verbonden. Ze hebben zelfs een andere inlogpagina. Ze vertegenwoordigen een ander veld van taken (auteur versus helpdeskauteur). Er is dus geen reden om uw klant in verwarring te brengen door hem beide toegangsmogelijkheden te bieden.

Wat uw interne processen betreft, is het technisch mogelijk om sommige klanten volledige gebruikers te bieden, en aan andere klanten alleen helpdeskgebruikers. Dit vereist echter nauwkeurige procesbeschrijvingen en trainingen voor uw agenten om ervoor te zorgen dat ze de verwerking van tickets uit deze zeer verschillende kanalen niet door elkaar halen. Vanwege de organisatorische problemen raden we ten zeerste aan om slechts één optie voor klanttoegang te kiezen.

Samengevat

Laten we de voorgaande informatie terugbrengen in een verteerbare vorm. Hier is een tabel met situaties die kunnen optreden op basis van het type toegang van uw clients tot uw systeem.

Klanttoegang tot de applicatie	Opties om ticket in te dienen (klant)	Meldingen van ticket (agent)	Opties om ticket bij te werken (klant)	Onze aanbevelingen
Zonder toegang	Stuur een e-mail naar een helpdesk-e-mailadres.	Agent verzendt e-mail via sjabloon vanaf het ticket.	Beantwoord de e-mail van de agent Stuur een nieuwe e-mail met #[ticket_id] in het onderwerp naar het e-mailadres van de helpdesk (zeldzaam, maar mogelijk)	Zorg ervoor dat e-mailsjablonen de ticket-ID in het onderwerp bevatten. En dat agenten voor elke situatie de juiste sjablonen gebruiken Wachtrijen voor binnenkomende tickets moeten gebaseerd zijn op de statussen die zijn geconfigureerd in de helpdeskinstellingen
Volledige gebruiker	Maak een ticket aan in het systeem via de knop "nieuwe taak". Stuur een e-mail naar het e-mailadres van de helpdesk	Standaard systeemmelding (niet aanbevolen) Agent verzendt e-mail via sjabloon vanaf het ticket	Voeg direct commentaar toe aan de ticketdetails Beantwoord de e-mail van de agent Stuur een nieuwe e-mail met ticket-ID naar het helpdeskadres (zeldzaam, maar mogelijk)	Schakel reguliere systeemmeldingen van het ticket uit Stuur ze alleen helpdesk-e-mails vanuit sjablonen Als u systeemmeldingen wilt inschakelen, zorg er dan voor dat deze worden verzonden vanaf een e-mailadres dat is verbonden met de helpdesk (om antwoorden te verwerken) Statuswijzigingen voor clientgebruikers in de toepassing niet toestaan Onderhoud wachtrijen voor binnenkomende tickets om te tellen met tickets die op alle toegestane manieren door klanten vanuit de applicatie zijn bijgewerkt Als u voor dit type toegang kiest, implementeer dan geen helpdeskgebruikers
Helpdeskgebruiker	Maak een ticket aan in het helpdeskportaal Stuur een e-mail naar het e-mailadres van de helpdesk	Agent verzendt e-mail via sjabloon vanaf het ticket.	Voeg direct commentaar toe aan de ticketdetails Beantwoord de e-mail van de agent Stuur een nieuwe e-mail met ticket-ID naar het helpdeskadres (zeldzaam, maar mogelijk)	Zorg ervoor dat e-mailsjablonen de ticket-ID in het onderwerp bevatten. En dat agenten voor elke situatie de juiste sjablonen gebruiken Wachtrijen voor binnenkomende tickets moeten gebaseerd zijn op de statussen die zijn geconfigureerd in de helpdeskinstellingen