Een vastgelopen browser aan de balie onderbreekt het scherm waarmee de medewerker werkt, maar vertelt niet vanzelf wat met de terminalbetaling is gebeurd. Na herstart moet de bestaande order en poging teruggevonden worden voordat een nieuwe handeling volgt. Voor een Yindle Mollie Terminal-pilot hoort deze herstelroute bewust te worden ontworpen. De medewerker moet weten welke referentie hij gebruikt, waar de actuele uitkomst wordt gecontroleerd en wie een onduidelijk geval overneemt.
Maak de bestelling opnieuw herkenbaar
In een fictieve showroom sluit de browser onverwacht nadat het betaalverzoek is gestart. De klant staat nog bij het apparaat en vraagt of hij opnieuw moet beginnen. De medewerker opent eerst de afgesproken orderomgeving en zoekt de betreffende bestelling terug. Gebruik een herkenbare orderreferentie en een inhoudelijke controle, zodat niet per ongeluk een vergelijkbare order wordt geopend. De nieuwe browserweergave moet de bestaande context kunnen tonen; de medewerker hoort die niet uit zijn geheugen opnieuw samen te stellen.
Leg in de pilot vast hoe een lopende betaalpoging bij de order wordt gevonden. De bestaande Yindle-terminalbouwsteen bevat een basis voor ordergebonden providerverzoeken en het opnieuw ophalen van betaalinformatie. Een volledig beproefd herstelpad na iedere browseronderbreking is daarmee nog niet als algemene producteigenschap bewezen. De eigen balieflow moet daarom met de gebruikte apparaten, rollen en schermen worden getest. Neem de benodigde herkenningspunten op in de werkinstructie.
Beoordeel de bestaande poging op actuele informatie
Na terugvinden moet de technische uitkomst worden gecontroleerd via geverifieerde providerinformatie. Bedrag en valuta moeten bij de betreffende order passen voordat zij als betaald wordt verwerkt. Een leeg of opnieuw geladen scherm is geen bewijs dat de eerdere poging niet heeft plaatsgevonden. Laat de medewerker de afgesproken beoordeling volgen en geef een onduidelijke uitkomst een eigenaar. Een extra klik op betalen is geen vervanging voor ontbrekende informatie over de bestaande poging.
Houd de klant intussen op de hoogte van de praktische stap: de medewerker zoekt de bestaande betaling terug en controleert de uitkomst. Vertel niet dat de betaling zeker is mislukt omdat de browser stopte. Als de klant moet wachten of later teruggebeld wordt, hoort daarbij een concreet aanspreekpunt. De serviceafspraak en het technische onderzoek moeten met elkaar verbonden blijven, zodat de klant geen los ticketnummer krijgt zonder dat iemand de bijbehorende order kent.
Test herstart op verschillende momenten
Gebruik fictieve orders en een afgesproken testopstelling. Onderbreek de browser vóór het verzoek, tijdens een lopende poging en nadat een uitkomst beschikbaar is. Laat een medewerker daarna de order terugvinden en het juiste vervolg kiezen. De herstelroute moet verschillen kunnen herkennen zonder dat de testleider vertelt wat achter de schermen gebeurde. Noteer welke informatie de medewerker mist en of een collega het open geval kan overnemen.
Werk de bevindingen in de pilotacceptatie uit en herhaal de relevante proef na belangrijke veranderingen in de balie-interface. Voor een duidelijke werkbak met ordercontext kun je Yindle Desk verkennen. Een specifiek herstel- of beheerscherm past bij maatwerksoftware. Het resultaat is dat een browsercrash de medewerker niet dwingt opnieuw te gokken: hij vindt dezelfde order en poging terug en baseert het vervolg op de gecontroleerde uitkomst.