Een klant bedenkt zich nadat het terminalverzoek is gestart: hij wil nog een accessoire toevoegen of een artikel weglaten. De winkel moet dan voorkomen dat de order verandert terwijl de lopende betaalpoging nog het eerdere bedrag vertegenwoordigt. Voor een terminalpilot hoort deze situatie expliciet in de werkinstructie. Eerst moet duidelijk worden wat er met de bestaande poging gebeurt; daarna kan de bedoelde nieuwe bestelling via de ondersteunde route verder.
Leg het wijzigingsmoment vast
In een fictieve showroom wil een klant tijdens het pinnen een extra stoel meenemen. De medewerker heeft de order al gecontroleerd en het verzoek is naar de terminal gestuurd. Een losse orderregel toevoegen is nu niet alleen een catalogushandeling. De bestaande poging hoort bij een eerdere ordercontext. Laat de medewerker het verzoek herkennen en de afgesproken procedure volgen, in plaats van tussendoor bedragen op verschillende schermen te veranderen.
De exacte stop-, annuleer- en herstelmogelijkheden moeten in de eigen toepassing zijn vastgesteld. De bestaande Yindle-terminalbouwsteen is een basis voor ordergebonden betaalverwerking, maar biedt geen algemene garantie voor iedere wijziging tijdens een lopende transactie. Maak daarom vooraf zichtbaar welke momenten een wijziging ondersteunen en welke eerst beoordeling vragen. De medewerker moet weten wie hij inschakelt als de uitkomst van de bestaande poging nog niet duidelijk is.
Beoordeel de bestaande poging vóór een nieuwe opdracht
De technische status moet worden gecontroleerd via de geverifieerde providerinformatie. Bedrag en valuta moeten bij de juiste vastgelegde ordercontext passen voordat de betaling als verwerkt wordt beschouwd. Een terugkerend baliescherm of een gewijzigde orderregel is geen bewijs dat een eerdere poging is verdwenen. Laat de pilotprocedure aangeven welke bron de uitkomst onderbouwt en hoe die uitkomst zichtbaar wordt voor de medewerker die de klant verder helpt.
Wanneer de bestaande poging is afgehandeld volgens de ondersteunde route, kan de nieuwe samenstelling opnieuw worden beoordeeld. Laat de klant en medewerker hetzelfde aangepaste orderoverzicht zien. Controleer product, aantal en het bedoelde totaal voordat een volgende betaalhandeling wordt gestart. Dit artikel schrijft geen financiële afhandeling voor; de winkel moet haar eigen goedgekeurde procedure voor verschillen en vervolgacties gebruiken. Het technische ontwerp hoort die procedure navolgbaar te ondersteunen.
Oefen drie momenten van dezelfde klantvraag
Gebruik fictieve orders en laat de vraag om een accessoire verschijnen vóór het verzoek, tijdens de poging en nadat betaling geverifieerd is. De medewerkers moeten kunnen uitleggen waarom het vervolg per moment verschilt. Observeer of zij de bestaande poging terugvinden en niet direct opnieuw beginnen. Een training waarin de wijziging altijd op het gemakkelijkste moment plaatsvindt, bereidt de balie onvoldoende voor op het werkelijke gesprek.
Laat de klantrol de aangepaste bestelling na de oefening opnieuw benoemen. Zo toets je of het gesprek en de uiteindelijke order hetzelfde nieuwe artikel en dezelfde hoeveelheid beschrijven, in plaats van alleen een gewijzigd totaal.
Leg bij iedere oefening vast welke informatie de medewerker nodig had en welke stap nog onduidelijk was. Gebruik die bevindingen om de ondersteunde route en schermuitleg aan te scherpen. Voor de operationele behandeling van zulke vragen kun je Yindle Desk verkennen. Een aangepaste order- en betaalinterface past bij maatwerksoftware. Het resultaat is dat een klantwijziging eerst met de bestaande betaalpoging wordt verzoend en daarna als een duidelijk gecontroleerde nieuwe bestelling verdergaat.