Piso WiFi Customer Dispute Scripts: What to Ask, What to Check, and What to Say

Part of the pillar: Piso WiFi Business. Also in Business, Vendo and Setup: Best Location and Permits.

Most Piso WiFi disputes are small amounts of money and short amounts of time, but they feel large to the customer who just paid and got nothing. How you respond in the first minute decides whether the customer leaves angry, leaves calm, or comes back tomorrow. This post is a scripts and decision guide only. It covers what to ask first, what proof to check, what to say, when a refund or re-credit is an operator decision, and what to record, for five common disputes: coin eaten with no credit, time lost after pause or reconnect, voucher rejected, slow speed, and machine offline.

This post does not repeat troubleshooting fix steps in full. Where a dispute points to a fault that needs fixing, it links to the relevant troubleshooting post by name, and you should follow that post for the fix. The job of this post is the conversation with the customer, and the decision you make while the customer is still standing there.

A note on refunds and re-credits that applies to every script below: a refund or re-credit is an operator decision, not a promise and not an automatic right on every complaint. You decide based on the proof you checked, the amount involved, and your own policy for that location. Say so plainly, decide once, and record what you decided. A vague promise made to end an argument will create a larger dispute next time.

How to Open Any Dispute Conversation

Before you reach the five scripts, use the same calm opening for every dispute. It costs less than a minute, and it prevents most arguments.

1. Listen first, without interrupting, and let the customer finish the story.
2. Ask which machine and location, what time it happened, and how much was paid or what code was used. Without a machine, a time, and an amount, you cannot check anything.
3. Check the proof described in the script below before you decide. Do not decide from the story alone, and do not accuse the customer of a mistake before you have checked.
4. Say what you found, in plain words, then say your decision, then say what happens next.
5. Record the dispute, even if you gave nothing. A record protects you if the same claim returns, and it shows you patterns, such as one machine generating the same dispute every week.

Keep your voice calm and your sentences short. Do not argue about who is right. Your job is to check, decide, and move on, not to win the conversation.

A Short Calm Wording Guide

Use these patterns, in your own words, for any dispute:

• Opening: “Let me check that for you. Which machine was it, and what time did it happen?”
• While checking: “I am checking the session list and the timer now, so I can see what the machine recorded.”
• When the proof supports the customer: “You are right, the machine shows the problem. Here is what I will do.”
• When the proof does not support the claim: “I checked the record, and it shows something different. Here is what it shows, and here is what I can do.”
• When you need time: “I need to check the machine on site before I decide. I will let you know by this time, and here is how to reach me.”
• When you decline: “I understand this is frustrating. Based on what the record shows, I cannot refund this one, and here is why. Here is what I can offer instead, if anything.”
• Closing: “Thank you for telling me. I have recorded it, so if it happens again on this machine we will see the pattern.”

Avoid phrases that blame the customer, such as saying they pressed the wrong button, before you have checked the machine. Avoid promises you cannot keep, such as saying it will never happen again, or that every future complaint will be refunded. Avoid discussing other customers, other machines, or your costs. The customer cares about their payment and their time, not about your expenses.

1. Coin Eaten With No Credit

This is the dispute customers feel most strongly, because they watched money go in and saw no time appear.

What to ask first

• Which machine and location?
• What time did it happen, as closely as the customer can remember?
• How much was inserted, and in what coins?
• Did the portal open, did the timer start, or did nothing happen at all?
• Is this the first time, or has it happened before on this machine?

What proof to check

• The session list for that machine around the stated time, for a session matching the amount and time.
• The timer record, if your platform keeps one, for any credit given at that time.
• The coin box count, where possible, compared with the session record for the same period.
• The machine itself, as soon as you can, for a jammed coin, a full box, or a coin slot fault.

What to say

• While checking: “Let me check the session list for that time, to see what the machine recorded for your payment.”
• If the record shows no credit for the payment: “The record shows no time was given for that payment, so I will re-credit the time or refund the amount now.” Then do it at once, while the customer is there, rather than asking them to return later.
• If the record shows credit was given: “The record shows time was given at that time. Can you show me the device you used, so we can check whether the timer is still running or the device disconnected?” A session can exist even when the customer did not see it, for example if the portal closed before the timer was noticed.
• If you cannot check at once: “I cannot verify this from here, so I will check the machine and let you know by this time. Please keep any receipt or note of the time, and here is how to reach me.”

When to refund or re-credit

Refund or re-credit as an operator decision when the session record shows no credit for the payment, or when you find a coin fault on the machine that matches the complaint. This is a decision, not a promise for every claim, and it should be based on the proof you checked. If the record clearly shows credit was given and used, explain that record, and do not refund the same session twice.

What to record

Date, time, machine, amount claimed, session record result, coin box check result, decision, and amount refunded or time re-credited, if any. For the fix itself, such as a coin slot repair or calibration, follow Piso WiFi Coin Slot Not Working rather than repeating those steps here.

2. Time Lost After Pause or Reconnect

Pause disputes are common because pause rules differ by platform and by setting, and customers often assume pause works the same way on every machine.

What to ask first

• Which machine and location?
• Was the session paid by coin or by voucher?
• Did the customer press pause, or did the device disconnect, run out of battery, or leave the area?
• How long was the pause or disconnection, and what time remained before it?
• What does the timer show now?

What proof to check

• The session list for that machine, for the session start, pause, resume, and expiry times.
• The pause settings for that machine, including any pause limit, pause count, or pause validity that applies to coin and voucher sessions.
• Whether the session expired during the pause or disconnection, under the settings in force at that time.

What to say

• While checking: “Let me check the session record and the pause setting for this machine, so I can see what happened to your remaining time.”
• If the record shows time was lost because of a setting the customer could not see: explain the setting in plain words, then decide. For example: “The machine allows a limited pause, and this session passed that limit, so the remaining time expired. I understand that was not clear, and here is what I will do for this session.”
• If the record shows a fault, such as a session disappearing after a resume: “The record shows the session did not resume correctly. I will re-credit the remaining time now.”
• If the record shows the session is still valid: “Your session is still active until this time. Let me help you reconnect to it on this device.” Then help, rather than only explaining.

When to refund or re-credit

Re-credit remaining time as an operator decision when the record shows a fault, a resume failure, or a setting that was not explained on the sign or portal. Do not promise that pause will always save time in future, because pause limits and validity rules apply, and those rules differ by machine. If the customer simply exceeded a stated pause limit, explain the limit, and decide whether a goodwill re-credit is right for this one case, without changing the rule for every future session.

What to record

Date, time, machine, payment type, session times, pause or disconnect reason, pause setting found, decision, and time re-credited, if any. For pause rules and fix steps in full, follow the Pause Time pillar and Piso WiFi Pause Time Limit, and for sessions that ended while paused, follow Piso WiFi Session Expired While Paused. This post covers the conversation and decision only.

3. Voucher Rejected

A rejected voucher feels like a wasted purchase to the customer, especially when the code was bought from you or from a seller at the same location.

What to ask first

• Which machine and location?
• Where and when was the voucher bought?
• What does the portal say when the code is entered, in the customer’s own words?
• Has the code been used before, on this machine or another device?
• Can the customer show the code, the receipt, or the seller record?

What proof to check

• The voucher record for that code, if your platform provides one: whether it exists, whether it was already redeemed, whether it expired, and which machine or session it was used on.
• The receipt or seller record, where one exists, for the purchase time and value.
• The portal entry itself, where possible, to check for a typing error, such as a similar looking character entered wrongly.

What to say

• While checking: “Let me check the voucher record for that code, to see whether it was already used, expired, or entered on another machine.”
• If the code was already redeemed: “The record shows this code was used at this time, on this session. If that was not you, tell me who else had the code, because a shared code can be used once.” Then decide based on the record and the receipt.
• If the code expired: “The record shows this code expired on this date. Here is what I can do for this one, and here is the expiry rule for future vouchers.” Make sure the expiry rule is also shown where vouchers are sold, so the next customer sees it before buying.
• If the code is valid but the portal rejects it: “The code looks valid in the record, so I will test it on the machine and re-credit it or replace it now.” Then test, rather than asking the customer to keep trying.
• If the code does not exist in the record: “I cannot find this code in the record. Please show me the receipt or the seller, so I can trace where it was sold.” Do not invent a replacement code on the spot without a record to support it.

When to refund or re-credit

Replace or re-credit as an operator decision when the record shows a valid, unused code that the portal rejects, or when a seller error is confirmed by a receipt. Do not replace a code that the record clearly shows was already used in full, unless you have separate proof of a seller or system error. A replacement is a decision for this case, not a standing promise that any rejected code will always be replaced.

What to record

Date, time, machine, code reference (never write a full live code in a shared log; record a partial reference or batch reference only), purchase source, voucher record result, decision, and replacement or refund given, if any. For voucher fix steps in full, follow Piso WiFi Voucher Not Working rather than repeating those steps here.

4. Slow Speed

Slow speed disputes are harder than payment disputes, because slow can mean many things, and the customer and the operator may be testing different tasks at different times.

What to ask first

• Which machine and location, and what time was it slow?
• What was the customer trying to do: messages, browsing, video, a call, or a download?
• Was it slow for one device or for everyone nearby?
• Is the customer’s device connected to the machine network, or to another network?
• Has it been slow all day, or only at a busy time?

What proof to check

• The session list, to see how many users were connected at that time.
• A speed test from the location, at a similar time if possible, using a device connected to the machine network.
• A speed test connected directly to the internet source, where possible, to separate a machine problem from an internet source problem.
• Whether a per user limit is set on that machine, and whether it explains the speed the customer experienced.

What to say

• While checking: “Let me check how many users were connected at that time, and test the speed here, so we can see whether it was the machine, the internet source, or the busy period.”
• If the test shows a real fault: “The test shows the connection is slower than it should be right now. I am checking the cause, and here is what I will do for your session.” Then follow the fix post, and tell the customer when to try again.
• If the test shows normal speed but the busy period explains the complaint: “At busy times many users share the same connection, so video and downloads slow down even when messages still work. Here is what I can do for your session, and here is the best time for video at this location, if that helps.”
• If the customer’s task needs more speed than the machine offers: say so plainly, without blaming the customer. For example: “This machine is suited to messages and browsing. Video calls need a faster connection than this location provides at busy times, so I will not promise a speed this machine cannot give.”

When to refund or re-credit

Refund or re-credit as an operator decision when the test confirms a fault at the time of the customer’s session, such as an outage, a source failure, or a machine fault that made the session unusable. Do not promise a refund for every slow session, because shared connections slow down at busy times even when nothing is broken. Decide case by case, based on the test result and the session record, not on how loudly the complaint is made.

What to record

Date, time, machine, customer task, number of users at the time, speed test result if taken, cause found, decision, and refund or re-credit given, if any. For slow speed fix steps in full, follow Piso WiFi Slow Speed rather than repeating those steps here.

5. Machine Offline

An offline machine creates disputes even from customers who did not pay, because they arrived, expected a service, and found nothing working. Handle these disputes quickly, because the customer has already wasted a trip.

What to ask first

• Which machine and location, and when did the customer find it offline?
• Did the customer pay before realising it was offline, or did they arrive and find no network?
• Is the machine showing no network at all, or a network with no portal?
• Has anyone at the location reported a power cut or an internet outage?

What proof to check

• The machine status, from your dashboard or monitoring log, for the time the customer reports.
• The session list, for any sessions that ended suddenly at that time.
• On site checks, as soon as possible: power, internet source, and portal, following the relevant troubleshooting post for the symptom found.
• Your monitoring log, for whether this machine has gone offline before, and how long it stayed offline last time.

What to say

• At once: “Thank you for telling me. Let me check whether the machine is back online now, and what happened at that time.”
• If the machine is still offline: “The machine is still offline. I am checking the cause now, and I will put up a sign with the expected return time as soon as I know it. If you paid and got no time, I will check that session and decide on a refund or re-credit.”
• If the machine is back online: “The machine is back online now. If your session was cut short, let me check the session record, and I will re-credit the remaining time if the record supports it.”
• If the cause is a power cut or an internet outage beyond your control: say so plainly, without blaming the provider in a way you cannot prove. For example: “The outage was caused by a power cut at this location. I cannot control that, but I can check your session and decide on the remaining time.”

When to refund or re-credit

Re-credit remaining time, or refund an unused payment, as an operator decision when the session record shows a session cut short by the outage and the customer did not receive the time paid for. Do not promise compensation for a trip to an offline machine where no payment was made, but do apologise, give a clear return time if you know one, and put up a sign so the next customer is not caught the same way.

What to record

Date, time, machine, outage start and end if known, cause found, sessions affected, decisions made, and refunds or re-credits given. For offline fix steps in full, follow Piso WiFi No Internet and Piso WiFi Portal Not Loading, depending on the symptom found, rather than repeating those steps here.

Decision Flow: Check, Decide, Record

Use this short flow for any dispute, in any order the facts require, before you close the conversation:

1. Ask: machine, location, time, amount or code, and what happened.
2. Check: session list, timer, voucher record, speed test, or machine status, as the script for that dispute describes.
3. Decide: refund, re-credit, replace, help to reconnect, or decline, as an operator decision based on the proof, not on pressure.
4. Say: what you found, what you decided, and what happens next, in plain words.
5. Record: the dispute, the proof, and the decision, using the log template below.
6. Fix: if the proof points to a machine fault, follow the linked troubleshooting post, and test as a customer before reopening fully.

If you cannot check at once, say when you will check, and keep that promise. A dispute left without a time for an answer becomes a second dispute.

Short Dispute Log Template

Copy this template, one row per dispute. Keep it in a private place, not on the machine or in a public post, and never write a full live voucher code in it.

Field	What to record
Date and time of complaint	When the customer reported it
Machine and location	Which machine the dispute refers to
Customer contact, if given	How to reach the customer with the decision, if they left one
Dispute type	Coin eaten, time lost, voucher rejected, slow speed, or machine offline
Amount or time claimed	What the customer says they paid or lost
Proof checked	Session list, timer, voucher record, speed test, or machine status, and what it showed
Decision	Refund, re-credit, replacement, help given, or declined, with amount or time if any
Fix followed	Troubleshooting post followed, if a fault was found, and test result
Follow up	Any promise made about a time for an answer, and whether it was kept

Review the log weekly. One machine with repeated coin disputes needs a coin slot check. One location with repeated offline disputes needs a power or internet check. One voucher batch with repeated rejections needs a seller and batch check. The log turns single complaints into decisions about repairs, signs, and settings.

Frequently Asked Questions About Customer Disputes

Should I always refund a customer who complains?

No. Check the proof first, then decide as the operator. Refunding every complaint, including claims the record does not support, teaches customers that a complaint alone is enough, and it hides real machine faults behind refunds. A fair check, a clear decision, and a record protect both you and honest customers.

What if the customer is angry and I cannot check the machine at once?

Stay calm, listen, take the machine, time, and amount details, and give a clear time for your answer and a way to reach you. Do not argue, do not promise a refund before checking, and do not ignore the complaint. Keeping the promised time for an answer matters more than giving an instant answer you cannot support.

What if the session record and the customer story disagree?

Show the customer what the record says, in plain words, without accusing them. A session can exist even when a customer did not see the timer, a code can be used on another device, and a pause limit can expire a session. Explain the record, offer help to reconnect or to test together, and decide based on the record plus any receipt or seller proof the customer can show.

Should I write full voucher codes in my dispute log?

No. Record a partial reference or batch reference only, plus the voucher record result. A full live code in a shared log can be copied and used by someone else, which creates a second dispute from the same code.

How do I handle the same customer complaining repeatedly?

Check the log for that machine and that customer pattern. If the same fault repeats, fix the machine, using the linked troubleshooting post, rather than refunding the same fault again. If the record repeatedly does not support the claims, explain the record each time, decide consistently, and keep the log as your evidence for the pattern.

What should I put on a sign to prevent disputes?

Put the rate, the pause rule in plain words, the voucher expiry rule, and a contact method for problems, at the machine and on the portal where possible. A sign written before a dispute prevents more arguments than any script written after one.

What to Read Next

If a dispute points to a coin fault, go to Piso WiFi Coin Slot Not Working. If it points to a voucher fault, go to Piso WiFi Voucher Not Working. If it points to slow speed, go to Piso WiFi Slow Speed. If the machine is offline, go to Piso WiFi No Internet, and if the portal will not load, go to Piso WiFi Portal Not Loading. If the dispute involves pause, go to the Pause Time pillar and Piso WiFi Pause Time Limit. If you monitor several machines and want to catch dispute patterns early, go to Piso WiFi Multi Machine Monitoring.