Van klantmail naar developer-ready ticket: zo automatiseer je de intake
"Hoi, de bestelpagina doet weer dat gekke ding, kunnen jullie er vandaag naar kijken?" Die mail is het begin van een ticket dat twee keer zoveel gaat kosten als nodig, want iemand mag veertig minuten uitzoeken wat "dat gekke ding" is. De intake is de goedkoopste fase van de hele keten om te verbeteren, en tegelijk de fase die de meeste bureaus overlaten aan wie de mail toevallig het eerst leest.
Waarom een ticket duur wordt voordat er code is
De kosten van een slecht omschreven ticket zitten niet in één lang gesprek. Ze zitten in een reeks kleine vertragingen die elk op zichzelf redelijk lijken.
- Een developer pakt het op, kan het niet reproduceren en legt het weer neer.
- Iemand mailt de klant een verduidelijkende vraag. Dat kost minimaal een dag, soms drie.
- Het werk wordt gedaan op een aanname. De aanname klopt niet. Het wordt opnieuw gedaan.
- Het wordt op drie punten geschat omdat niemand wist dat het de facturatiemodule raakte.
- Het zakt naar de onderkant van de backlog omdat niemand de omvang kan inschatten, precies het mechanisme uit voorkomen dat klanttickets blijven liggen.
Wat een developer-ready ticket echt bevat
Geen sjabloon met vijftien verplichte velden — die staan binnen twee weken vol met "n.v.t.". Zes dingen, waarvan er drie meestal al in de mail staan.
| Onderdeel | Waarom het telt | Waar het vandaan komt |
|---|---|---|
| Klant, project, omgeving | Bepaalt de repository, het contract en de urgentie | De afzender en het systeem, automatisch |
| Wat er gebeurde, in de woorden van de klant | Het primaire bewijs, letterlijk geciteerd | De mail zelf |
| Reproductiestappen, of een URL en een tijdstip | Het verschil tussen tien minuten en een middag | Eenmalig gevraagd, bij de intake |
| Verwacht tegenover werkelijk gedrag | Laat zien of dit een defect of een wijzigingsverzoek is, en dus wie betaalt | Afgeleid en bevestigd |
| Acceptatiecriteria | Legt "klaar" vast vóór de start en beëindigt de discussie erna | Bij de intake geschreven, niet bij de review |
| Prioriteit tegenover de SLA | Vertelt het team of dit de sprint onderbreekt | Het contract, plus oordeel |
Het onderscheid tussen defect en wijzigingsverzoek verdient extra aandacht. "De export mist de btw" is een bug als de specificatie zegt dat btw erin hoort, en een betaald wijzigingsverzoek als dat er niet staat. Dat bepalen bij de intake is een gesprek van twee minuten. Het bepalen na oplevering is een onderhandeling.
Doe het werk waar de mail binnenkomt
Het structurele probleem met intake is dat die in de ene applicatie gebeurt terwijl het ticket in de andere leeft. Wie de mail leest, moet van context wisselen, de juiste klant en het juiste project zoeken, plakken, herschrijven en bijvoegen. Dus wordt het uitgesteld, en een uitgestelde intake is een ticket dat een dag te laat begint.
Het ticket vanuit de mailclient aanmaken haalt die wrijving volledig weg. De Outlook-invoegtoepassing van Suporta leest het bericht in het leesvenster, stelt klant, project en prioriteit voor, maakt het ticket aan en laat je de tijd schrijven die je net aan het gesprek besteedde, zonder de mailbox te verlaten.
Waar AI bij de intake echt helpt
Dit is een van de duidelijkste toepassingen van AI in een bureauproces, want de taak is afgebakend, de invoer is tekst en een mens beoordeelt het resultaat direct. Drie concrete taken:
- Classificatie. Welke klant, welk project, welke prioriteit. Het systeem kent je bedrijven en projecten al, dus dit is een matchingprobleem met een kleine antwoordruimte.
- Uitwerking. Een klacht van twee regels omzetten in een gestructureerd ticket met waarschijnlijke reproductiestappen en concept-acceptatiecriteria, in de taal waarin het ticket is geschreven.
- Schatting. Een voorstel in story points, vooral nuttig als iets om het mee oneens te zijn. Een startpunt is beter dan een leeg veld.
De grenzen tellen net zo zwaar als de mogelijkheden. Uitwerken stelt voor, het beslist niet: een mens bevestigt de klant en de prioriteit, want een P1 op het verkeerde contract is erger dan helemaal geen ticket. En de oorspronkelijke mail blijft eraan hangen, zodat de uitwerking altijd tegen de bron te controleren is.
E-mail is niet de enige deur
Dezelfde intakenorm hoort te gelden ongeacht waar de melding vandaan komt, en sommige bronnen komen beter gestructureerd binnen dan een mens ooit zou doen.
- Klantportaal. Het formulier kan vooraf om de omgeving en de stappen vragen, en dat is de goedkoopste plek om ze te krijgen.
- Monitoring. Een Sentry-melding die automatisch een ticket wordt, brengt een stacktrace en een frequentie mee, meer dan de meeste menselijke meldingen bevatten.
- Chat. De slechtste bron, want het voelt als een gesprek en laat geen spoor na. Komt er een verzoek via Slack, dan is het antwoord elke keer: "ik maak er een ticket van".
- Telefoon. Prima, mits het ticket tijdens het gesprek wordt geschreven en niet achteraf uit het hoofd.
Het volhouden zonder ticketpolitie te worden
Een werkbare intakenorm
- check_circleElke dag is één persoon met naam verantwoordelijk voor de intake, op een vast moment
- check_circleElk ticket heeft een klant, een project en een prioriteit voordat het in de wachtrij komt, zonder uitzondering
- check_circleDe originele tekst van de klant hangt er altijd bij en wordt nooit aangepast
- check_circleAcceptatiecriteria worden bij de intake geschreven, niet bij de oplevering uitonderhandeld
- check_circleDefect of wijzigingsverzoek wordt bij de intake bepaald en vastgelegd
- check_circleMeldingen via chat of telefoon krijgen ter plekke een ticket, niet later
- check_circleBij onduidelijkheid gaat er één specifieke vraag naar de klant, geen drie vage
Het realistische doel is geen perfecte tickets. Het is dat een developer bij de meeste tickets kan beginnen zonder eerst iets te vragen. Van "soms" naar "meestal" komen levert doorgaans meer capaciteit op dan welke toolwijziging in deze lijst ook.
Gerelateerde artikelen
Alle artikelen arrow_forward
Hoe voorkom je dat klanttickets blijven liggen?
Niemand besluit een ticket te negeren. Het wordt dinsdag toegewezen, is echt minder urgent dan de brand ernaast, en de maandag erna schrijft de klant in hoofdletters om een update.
Klantportaal vs traditionele helpdesk voor softwarebureaus
De vraag is niet wat moderner is. De vraag is wie wat kan zien, waar de historie staat, en of een klant zelf kan achterhalen wat er met zijn melding gebeurt zonder jou te mailen.
AI coding agents voor softwareteams: waar menselijke controle nodig blijft
De nuttige vraag is niet of een agent de wijziging kan schrijven. De vraag is wie verantwoordelijk is als het misgaat, en wat het proces daaraan doet.