Most shop owners are told that a QR code "sends files to the shop" and accept it, which is fine until something does not work and nobody can tell why. This guide explains the actual mechanics — what the code contains, what the customer sees, what your system does with the file, and where the process can fail. It is deliberately technical where that helps and deliberately not technical where it does not.

What is actually encoded in the counter QR code

A QR code contains text — that is all. It does not contain files, storage, or your shop's data. In a counter setup the code holds a web address, and that address identifies your shop so the page on the customer's phone knows where to send the file.

• The QR code is a machine-readable version of a URL. Point a phone camera at it and the phone opens a browser.
• The URL identifies your shop. That is the only job it does.
• Nothing about the file happens at scan time. The scan is a browser navigation, not a transfer.
• Because it is just a URL, you can reprint the same code forever, and a customer can re-scan it on a different day.

This is why the code does not break. A QR code holding a fixed address has nothing to expire, and a customer who scanned it last month can scan it again today and get the same working page.

What the customer actually sees

The customer experience is the thing that decides whether a counter system works, and it is shorter than most vendors imply.

• They point their phone camera at the code. A notification appears with your shop name.
• They tap it, and a page opens in their normal mobile browser. No app, no store, no account.
• They pick files from their phone. There is usually a visible file size limit and accepted formats.
• They set print options — colour or black and white, copies, single or double sided, page range, and sometimes paper size.
• They see the cost calculated from your rate, so there is no argument at the counter about the price.
• They submit, and the job appears in your queue in arrival order.

The critical design point is step four. If the customer sets the specifications, the shop owner receives them as data rather than having to interpret a chat message. That is the entire difference between a system that works and one that does not.

File formats and size limits

Counters mostly receive two kinds of file, and they behave very differently. Understanding this removes most upload problems before they happen.

The limits that matter in practice are per-file size and total job size. A counter system typically allows a generous per-file allowance — often 100 MB or more — and a much smaller total per job, because a customer uploading forty phone photos of a hundred-page document is a different situation from a customer uploading one file.

• Ask for a PDF where the customer has one. It is smaller, sharper, and prints as it previewed.
• For photographed documents, ask the customer to turn off the flash and to photograph flat, not at an angle. Angled shots need perspective correction and rarely survive it.
• If a customer has a Word file, they should export to PDF. This is a thirty-second task for them and it removes an entire class of problem for you.
• Watch for the reverse case — a customer photographing a screen instead of using their own file. Screens moiré badly and the result is usually unusable.

What happens between upload and print

Once the customer submits, the file goes to storage and an entry appears in your queue. From there the sequence matters, because this is where most "the system lost my file" complaints come from.

• The file uploads to temporary storage. The job is not yet printable — it is a pending entry with a customer reference.
• You see it in the pending queue, in arrival order, with the file name and the specifications the customer chose.
• You open the job, preview it, and confirm the settings are what you want. This is the last chance to catch a wrong page count.
• You print. Depending on your setup this is a print command from the browser dashboard, a send from the Windows desktop agent, or a print from the Android app.
• The job moves to completed. Within the retention window you can restore it to pending if something went wrong, which is much cheaper than asking the customer to resend.
• The file is deleted automatically, on a fixed schedule, whether or not it was ever printed.

That last point is the one most shop owners miss. A system that keeps files until you delete them is a liability, and it grows silently. Automatic deletion on a fixed schedule is the only version of this that is genuinely safe.

Where it fails, and why

How to get the codes printed properly

• Print at least 3 cm square. Smaller codes fail more often on older phones and from an angle.
• Use a light, matte background. Glossy paper and dark backgrounds both reduce contrast and cause scan failures.
• Add a human instruction next to the code — "Scan to upload your file" — because a bare code on a wall is ignored by a surprising share of customers.
• Print several and put them in more than one place: the door, the counter, and the rate board.
• Never place a QR code over a busy photograph or pattern. Contrast is what the camera reads.

Where to go next

For the practical rollout, our contactless counter setup guide covers placement, staff training and handling the transition from WhatsApp. For the channel this replaces, our guide to ending the WhatsApp queue explains why the old arrangement breaks down and what it costs. And if you want the customer-facing side explained, our QR ordering guide covers what a customer should expect from the whole flow.