How to Send Customer Updates With a QR Code

A bike comes in for a gear cable and a bottom bracket. It’ll be ready some time this afternoon, probably. The customer is about to walk out for the day, and the only thing left to arrange is how they’ll find out. The workshop is invented; the awkward moment is ordinary.

Upd8All is a free app that lets a business send short one-way updates, such as order-ready alerts, to customers who scan a QR code. There are no accounts, and no phone numbers are exchanged.

This article covers the sending half: creating a channel, naming it, showing the code, and reading what the app tells you afterwards. What lands on the customer’s phone after the scan is the receiving half, and it’s covered separately. Both halves are simple. They fail in different places.

Key Takeaways

• The whole sequence is four steps: tap “New upd8 code”, name the channel, show the code, and let the customer scan. There are no accounts and no sign-up, for either side.
• Screenshot the code while it’s on screen. Once the popup closes there is no in-app way to bring that code back, and a new channel is the only alternative.
• After sending, the app shows a delivery confirmation and nothing else. No receiver count, no read status, no way to tell who is watching.
• Ofcom’s 2026 report puts 20% of online United Kingdom adults in a smartphone-only position (Ofcom, 2026), which is exactly the device this kind of channel asks for.

What do you need before you start?

Two things, and you probably have both. A phone with the app on it, and somewhere to hold that phone steady while a camera points at it. There is no reader to buy, no printer to feed and nothing to plug in.

The customer’s side is shorter still. A phone with a camera and a working connection covers it. The customer does not need the app: scanning the QR code opens the updates in their browser through Upd8 Go.

What it takes	The business side	The customer side
Device	A smartphone with the Upd8All app installed	A smartphone with a camera and an internet connection
The app	Yes. Sending happens inside it	No. The scan opens the updates in a browser instead
An account	None. There are no accounts and no sign-up, for either side	None
A phone number or email address	Not collected. No phone numbers or email addresses are exchanged between the business and the customer	Not given
Extra hardware	None beyond the phone already in a pocket	None
Cost	Free to use	Free to use

That customer-side row is worth sitting with, because it inverts something. Ofcom’s 2026 report on adults’ media use puts 20% of online United Kingdom adults in a smartphone-only position, up from 12% in 2019 (Ofcom, 2026).

For most online services that’s a constraint to design around. For a scan-to-receive channel it’s the whole requirement, already met, because the only device involved is the one that person already relies on. Ofcom also reports 70% of smartphone-only users saying they don’t feel disadvantaged, on bases of 1,408 smartphone-only against 5,621 other internet users (Ofcom, 2026).

Some customers still won’t be reachable this way. In 2024, 2% of United Kingdom households had no mobile phone at all (DSIT, 2025). That figure counts mobile phones rather than smartphones, so a household with a basic handset sits outside it and still cannot scan anything. Those customers need telling the old way, and it’s worth deciding in advance what the old way is.

If the underlying pieces aren’t familiar yet, how the app and the channel fit together sets out the mechanism before any of the operational judgement below.

How do you create a channel and show the QR code?

Four steps, and the third one is where people close things too early:

1. Tap “New upd8 code” in the app. This creates the channel and generates its QR code in one action.
2. Give the channel a name. Anything that tells you which job it belongs to.
3. Screenshot the code while the popup is open. Then show the screen to the customer.
4. Let them scan, and check they’ve got it. A page opening on their phone is the confirmation.

Step two is the only one carrying a decision. The name you type is not private housekeeping. The receiver sees it as the Topic, and it travels with every update you send on that channel.

So a workshop naming a channel “Blue Cannondale” has told the customer which bike this is about, before a single message goes out. A job number does the same thing if the customer was given the number. “Channel 3” tells them nothing.

The overwrite rule is worth knowing exactly. If the receiver’s own Topic field is empty, your next update fills it with your label. If they’ve already set a label of their own, yours never overwrites it. Sender and receiver can end up calling the same channel two different things, and nothing breaks when they do.

Channels are one-way and messages are capped at 40 characters, so the Topic is doing real work. It carries the context that won’t fit in the message. Getting the message itself right is its own skill, and choosing the words that fit inside 40 characters goes through it properly.

A repair trade doing this all day has more process to think about. There’s a shift-level version of the same job in running this across a workshop day.

Why should you screenshot the code before you close it?

Because there is no second chance at it. Once the popup showing a channel’s QR code has closed, the app offers no route to bring that code back on screen. A screenshot taken while it was open is the only copy that survives.

The consequence lands on a specific person. It’s the customer who turns up ten minutes later, or whose camera wouldn’t focus, or who said they’d do it outside and then didn’t. Without a screenshot, that customer cannot be added to the channel you already made. You create a fresh channel instead, and now you’re running two for one job.

The workaround itself is documented, in a different setting. Nielsen Norman Group’s QR code usability guidelines say this about screenshots of codes (Nielsen Norman Group, 2024):

“They may be able to take a screenshot of the QR code and then long-press it in the Photos app, but many users will not know that.”

The scope of that observation matters here. NN/g is describing a same-device problem there, where one phone has to display a code and scan it at the same time. A counter is a two-device arrangement, staff phone showing and customer phone scanning, so the objection isn’t aimed at it.

What does carry across is the smaller half of the sentence. The screenshot route exists, and most people don’t think of it.

Then treat the resulting image with a bit of care. It sits in a camera roll alongside everything else, and it stays usable for as long as the channel it points at exists. Anyone who ends up holding a copy holds the same access the customer at the counter got. That means not forwarding it around a staff group without a reason, and not printing it onto something that walks out of the building.

When does the customer actually scan it?

While they’re still stationary and still thinking about the job. That’s a shorter moment than it feels like from behind the counter.

Nielsen Norman Group’s QR code usability guidelines put a rule of thumb on the scan itself, at 15 seconds (Nielsen Norman Group, 2024):

“assume users need at least 15 seconds to scan a QR code”

That’s a design assumption rather than a measured result, and the guideline words it exactly that way. Below that threshold, its advice is a short memorable URL instead of a code.

The arrangement has a precedent outside customer service. The European Commission’s documentation for the EU Digital Identity Wallet describes a proximity scenario at a hotel front desk (European Commission, 2026):

“The service provider, the hotel front desk clerk, requests identification through a verifier device, which generates a QR code.”

That’s identity verification, not status updates, and the two jobs have almost nothing else in common. What transfers is the shape: a code generated by the staff member’s verifier device for one interaction, rather than a fixed code printed on a wall.

Where the code fits in an ordinary handover:

1. After the job details are settled, not before. You need to know what the job is to name the channel usefully, so booking-in comes first.
2. While the customer is already stopped. Paying, handing over keys, signing a sheet: their phone is usually already in a hand.
3. Before they’ve picked their bag back up. Once somebody has turned towards the door, the scan is competing with leaving.
4. Not while three people are queueing behind them. A code taken to deal with later tends not to get dealt with later.

None of that is a rule about what’s possible. A code that has been saved opens the same channel afterwards, from anywhere. It’s a rule about what actually happens in the short window you actually get.

If the camera won’t pick the code up at all, what makes a scan fail and what to check first runs through the usual causes in order.

What do you see after you send?

A delivery confirmation. That is genuinely all of it.

Sending itself is the short part. Once someone has scanned, anything you type on that channel goes to everyone holding that code, up to 40 characters at a time, one way only.

There is no receiver count on a channel, so the app never tells you how many people are attached to it. There is no read status, no delivered-to-device tick, and no way to distinguish a customer following the channel from a customer who scanned and forgot. You sent it, and the servers took it.

Say that out loud before building a workflow on it, because it rules some jobs out. If your process depends on proving that one named person received one specific message, this is the wrong tool and no setting will change that. A signed-for handover and a shout across a workshop are different jobs, and this is much closer to the shout.

What the confirmation does tell you is that the message left. That’s worth having, and it’s the boundary of what it means.

Whether one-directional messaging suits the work is the bigger issue underneath. Read deciding whether one direction is enough before a process comes to depend on it.

How many channels should you run?

As many as the jobs need. A sender can run several channels at once and scroll through them as a list, with no theoretical limit on how many.

The limit that does exist is on your own phone rather than the servers. Keeping a very large number of channels active can degrade performance on the sending device, so a list nobody ever prunes eventually costs something. On the other side there’s no practical limit for normal business use on how many people join a single channel.

One channel per customer

This is the repair-trade shape. Each job is separate, each customer wants a different sentence, and the channel name identifies whose job it is.

The gain is that the message can be specific. “Wheel done, brakes tomorrow” means something to exactly one person, and nobody else is reading it. The cost is a code shown and a name typed for every customer, plus a list that grows through the week and needs clearing.

One channel for the whole shift

This is the collection-point shape. One code sits at the counter, everyone waiting scans the same one, and a single message reaches all of them at once.

The gain is that setup happens once a day rather than once a customer. The cost is that every message is public to that channel, so nothing identifying can go in it. Messages have to label themselves instead, the way “Order 42 ready” does.

Deciding between them, in the order the questions actually matter:

1. Does the update change per person? “Ready” is the same line for everybody. “Awaiting a part from Tuesday” is not.
2. Can a customer tell your message is theirs? On a shared channel, every message has to carry its own identifier or it’s noise.
3. How long is the wait? Minutes at a counter suits one shared channel. A job spanning two days suits its own.
4. How much typing fits between other work? A channel per customer is a real cost at a busy counter, and it’s the reason most shared channels exist.

Most trades end up running both. A shift channel for the collection queue, and individual channels for the jobs that need a sentence nobody else should see.

The code outlives the job it was made for

A job ends. The channel made for it does not end with it, and that gap is where the tidy mental model breaks.

The bike goes out of the door and the customer stops caring by teatime. Deleting the channel on your side stops you sending on it, and that is where your control ends. The channel itself goes when the periodic purge removes channels older than roughly 30 days. That purge is manual rather than clock-driven, so it can run late, and no fixed deadline should be relied on.

Meanwhile the code still opens the channel for anyone holding a copy, and what the customer sees in Upd8 Go explains that end of it.

So the habit worth building is about the code, not the channel. Decide where that screenshot lives, and delete it when you close the job sheet, because that is the copy you can still do something about.

Frequently Asked Questions

What happens if I close the QR code before the customer scans it?

That code is gone for good, and nothing in the app will produce it again. The channel is a different matter. It keeps working for everyone already holding the code, and your updates still reach them. What’s lost is the ability to add anyone new, so a customer who arrives later needs a fresh channel. That means typing every update twice, once on each.

Can I run a separate channel for every customer?

Yes. What caps the number isn’t capacity at the far end, it’s the handset doing the sending. So the useful discipline is pruning, not counting. Pick a fixed moment and hold to it. At the end of each week, delete every channel whose job is closed, and bin the screenshot of its code in the same pass. A list nobody ever clears is the version of this that gets awkward.

What do I see if nobody has scanned the code yet?

The same thing you’d see if fifty people had. From inside the app there’s no way to tell an empty channel from a busy one. The consequence is easy to miss. A scan that quietly failed at the counter looks identical to one that worked, right up until the customer turns up asking. Nothing arrives later to correct that impression.

Should I treat a screenshot of the code as confidential?

Treat it like a door key, not a receipt. Anyone holding a copy can join that channel and read its History, and using it doesn’t spend it. Give it one home: a single folder on the work phone, tied to the job it belongs to. Then delete it the day the customer collects, not whenever the channel eventually goes. The mechanism behind that is covered in how a saved code behaves for the receiver.

What happens when I delete a channel?

Deleting a channel on your side stops you sending on it. It does not withdraw the code that was handed out. Anyone holding a saved image or link can still join and see the History until the channel is actually purged from the servers. That purge is a manual process that runs after about 30 days rather than on a fixed date. Deletion and disappearance are not the same moment.

Sources

• Department for Science, Innovation and Technology, “Digital Inclusion Action Plan: First Steps”, published 26 February 2025, retrieved 2026-09-01, https://www.gov.uk/government/publications/digital-inclusion-action-plan-first-steps/digital-inclusion-action-plan-first-steps
• European Commission, “Identification in proximity scenarios”, EU Digital Identity Wallet documentation, last updated 11 February 2026, retrieved 2026-09-01, https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/930451396/Identification+in+proximity+scenarios
• Nielsen Norman Group, Tanner Kohler, “13 QR-Code Usability Guidelines”, published 9 February 2024, retrieved 2026-09-01, https://www.nngroup.com/articles/qr-code-guidelines/
• Ofcom, “Adults’ Media Use and Attitudes report 2026”, published 2 April 2026, retrieved 2026-09-01, https://www.ofcom.org.uk/media-use-and-attitudes/media-habits-adults/adults-media-use-and-attitudes