Customer service
How to build a vending machine QR support flow that actually resolves requests
A QR sticker is not a service system. The useful part begins after the scan: identify the machine, collect the minimum evidence, protect the customer, route the work, and close the loop.
- Published
- September 14, 2026
- Reading time
- 10 minute read
Key takeaway
Use one durable QR identity per machine and let the customer choose the request type. Every submission should produce a trackable record and a clear operational next step.
Design principle
Put one support identity on the machine
The customer should not need to type a location name, serial number, or machine description that the operator already knows. A machine-specific QR link can attach that context before the form opens.
Keep the printed code stable even when the support message or form changes. Reprinting every sticker because a phone number, workflow, or product changes creates unnecessary field work. The QR record should resolve to a current public support experience while preserving the machine identity.
Print a short explanation beside the code: what the customer can do, whether contact details are optional, and how status updates work. Test the actual sticker at arm's length, in poor light, and with more than one phone before deployment.
Customer choices
Separate requests by the outcome they need
Do not put every field on the first screen. Ask for the request type, then reveal only the information needed to make that decision. Explain why sensitive fields are requested and avoid collecting card numbers, government IDs, or unnecessary personal data.
- Refund request: item, amount, payment method, approximate time, and optional evidence.
- Machine problem: what happened, whether money was taken, selection details, and safety urgency.
- Product request: requested item or category, with allergy information treated as context rather than a stocking promise.
- General feedback: a short message that does not force the customer through refund fields.
Operator workflow
Move every request through a visible resolution loop
- 01
Acknowledge
Confirm receipt immediately and provide a secure status link or reference. Do not promise a refund or completion before the operator has reviewed the request.
- 02
Triage
Classify urgency, request type, machine, location, payment method, and likely owner. Safety issues and repeated payment failures should not wait behind ordinary product suggestions.
- 03
Decide
Approve or decline the requested outcome with a reason. A product request may become an assortment-review item; a machine issue may become assigned field work; a refund may require external payment evidence.
- 04
Assign
When physical work is needed, connect the ticket to the employee, route stop, due date, machine instructions, and completion evidence. Avoid copying the issue into a disconnected task list.
- 05
Update
Send branded, plain-language updates when the status meaningfully changes. Include a safe link rather than exposing private operator pages or raw internal identifiers.
- 06
Resolve and learn
Record the final action, close related assignments, ask for a lightweight rating, and review recurring failures or requests by machine and location.
Worked example
One failed vend should create one connected record
A customer scans the code after a card payment is accepted but the selected drink does not dispense. They choose Refund, enter the amount and approximate time, and attach a photo of the machine display. The machine and location are already attached by the QR link.
The operator sees the request in the service queue, checks for duplicate submissions, and approves the refund record. Because two similar failures exist for the same selection, the ticket is assigned to the next field route with instructions to inspect the motor and photograph the tested slot.
The customer receives a secure status update without access to the operator workspace. The field employee completes the service evidence. The ticket closes with the refund status and repair outcome attached. Finance records the refund once; service history keeps the machine pattern; the next assortment decision has accurate context.
Service management
Review the signals that protect trust and route economics
Do not publish a response-time promise the team cannot meet. A narrower, honest service expectation is more useful than an instant-response claim that ends in silence.
- Time to first human review, separated from the automatic acknowledgement.
- Open requests past the stated service target.
- Repeat failures by machine, slot, and payment type.
- Approved refunds awaiting evidence of payment.
- Product requests grouped by location, not treated as universal demand.
- Resolution rating and unresolved customer replies.