Common NFC Deployment Mistakes
The most frequent NFC deployment error is assuming that a tag will simply work once programmed and stuck in place. In practice, the physical environment dictates whether a visitor's phone can read the tag at all.
Placing tags at awkward heights or angles is a common oversight. If a visitor has to crouch, stretch, or tilt their phone at an unnatural angle to make contact, many will not bother. The sweet spot for most general deployments is roughly waist to chest height on a flat, unobstructed surface, with the tag facing the direction from which people approach.
Another mistake is failing to account for phone cases. A thick rugged case adds millimetres of gap between the NFC antenna in the phone and the tag. Tags with a very short read range — some budget NTAG213 stickers fall into this category — may not register through a case at all. Testing with a range of common case types before committing to a bulk order avoids this problem entirely.
Not locking the tag after programming is a less obvious but serious error. An unlocked tag can be overwritten by anyone with an NFC writing app. In a museum or retail setting, this means a visitor could replace your exhibit URL with something else. Most tag management apps and many bulk programming tools offer a lock command; using it should be part of the standard workflow.
Deploying NFC without any visible cue or instruction also undermines uptake. Unlike a QR code, which is visually recognisable, a bare NFC tag looks like a sticker or badge. A clear call to action — "Tap your phone here" — alongside a recognisable NFC icon is essential, particularly for audiences unfamiliar with the technology.
Finally, relying on NFC as the sole channel in any public-facing deployment is risky. Some phones have NFC disabled by default, some users do not know where their antenna is located, and some operating-system versions handle NFC intents differently. A parallel channel — typically a QR code or a short URL printed nearby — ensures the content remains accessible when NFC fails.
Common QR Code Deployment Mistakes
Poor print quality tops the list. A QR code that works on screen can fail completely when printed at small size on rough or absorbent stock. The modules become blurred, the quiet zone gets encroached upon by surrounding graphics, and scanning apps can no longer distinguish the pattern. As a rule of thumb, the printed code should be large enough that its smallest module is at least a few millimetres across, and the quiet zone — the blank border around the code — should be at least four modules wide on all sides.
Placing codes in locations with poor lighting, glare, or physical obstruction is equally problematic. A code behind reflective glass, under harsh directional light, or at ankle level where it is partially hidden by fixtures will see low scan rates regardless of how good the underlying content is. Walk the route at different times of day and check for reflections, shadows and sight-line obstructions before finalising positions.
Using static codes for content that will change is a mistake that creates ongoing maintenance burden. A static QR code encodes the destination URL directly. If that URL changes — because a page moves, a campaign ends, or a domain is migrated — every printed instance becomes a dead link. Dynamic QR codes, which encode a short redirect URL managed on a server, allow the destination to be updated without reprinting. For any deployment expected to last more than a few weeks, dynamic codes are the safer choice.
Failing to test across multiple devices and scanning apps before going live is another recurring error. Different apps handle error correction levels, inverted colours and non-standard foreground colours differently. What scans reliably in one app may fail in another. Testing with the built-in cameras on both iOS and Android, plus at least one third-party scanner app, provides reasonable confidence.
Lastly, placing a QR code with no context about what happens after the scan erodes trust. Visitors are understandably cautious about scanning codes that could lead anywhere. A short label — "Scan for the audio guide" or "Scan to view today's timetable" — sets expectations and improves scan rates.
Using QR Codes Without a Mobile-Optimised Landing Page
A QR code is, by definition, a mobile interaction. The user is holding a phone, standing in your venue, and expecting an immediate, useful result. Sending that person to a page designed for a desktop browser is one of the fastest ways to waste the scan and damage trust.
The symptoms are familiar: text too small to read without pinching, navigation menus that are difficult to tap, images that load slowly over a venue's Wi-Fi or mobile data, and page layouts that require horizontal scrolling. A visitor who encounters any of these will likely leave the page within seconds, and the opportunity to deliver information, a promotion, or a wayfinding prompt is lost.
There are practical checks to run before linking a QR code to any page. Open the destination URL on a phone with a modest screen size — not the latest flagship — and load it over a 4G or 5G connection rather than office Wi-Fi. Check whether the text is legible without zooming, whether tap targets are large enough to use comfortably, and whether the page loads within a few seconds. If any of these fail, the page needs adjustment before it goes behind a QR code.
Heavy pages are a particular problem in venues where hundreds of visitors might scan simultaneously. Large hero images, auto-playing video, and third-party tracking scripts all add weight. Stripping the page down to the essentials — the specific content the QR code promised — improves both load time and usability.
It is also worth considering whether the page requires a login, download, or plugin to function. Asking a visitor who has just scanned a code in a museum or shop to create an account or install something is a near-certain abandonment point. The content should be immediately accessible, with any deeper engagement offered as an optional next step rather than a prerequisite.
Placing NFC Tags on Metal Surfaces Without Preparation
Metal surfaces are one of the most common causes of sudden, unexplained NFC failure. A tag that reads perfectly when held in the air or stuck to a plasterboard wall can become completely unreadable when placed directly onto a metal fixture, shelf edge, or display stand.
The reason is straightforward. An NFC tag contains a coiled antenna that resonates at a specific frequency when energised by the reader's magnetic field. A conductive metal surface in direct contact with that antenna disrupts the magnetic field, effectively detuning the tag and collapsing its read range to zero or near-zero. The tag is not damaged; it simply cannot communicate.
The practical signs are clear: a tag that previously worked at several centimetres now requires physical pressure or will not read at all once mounted. If you observe this after installation, a metal surface behind or beneath the tag is the most likely cause.
The solution is to use tags specifically designed for on-metal deployment. These tags incorporate a ferrite layer — a thin, non-conductive sheet — between the antenna and the adhesive backing. This layer isolates the antenna from the metal, allowing the magnetic field to develop normally. On-metal tags are slightly thicker and more expensive than standard stickers, but they are the only reliable option for direct metal mounting.
Where on-metal tags are not available, a spacer can sometimes provide enough separation. A few millimetres of non-conductive material — foam tape, acrylic block, or cardboard — between the tag and the metal surface may restore readability, though this approach is less predictable than a purpose-built ferrite-backed tag and should always be tested on-site before a full rollout.
Other surfaces can also cause problems, though less severely. Water and high-moisture environments can attenuate the signal, and very thick glass or stone can reduce range. As with metal, the practical safeguard is to test a sample tag in the exact position and on the exact material before committing to a deployment.
