What to check before printing
Quality checks for bulk table tents should start on screen, before any paper is used. Confirm that every row in the source data has a destination, that no two rows share an identifier that should be unique, and that whether each tent points at the right table or area. Open a sample of destinations in a browser and confirm that each page loads, shows the right content, and works on a phone screen. Check the printed text that will sit beside each code, including names, references, and dates, because a correct code next to wrong text still fails the person using it. Compare the layout against the brief for size, margins, and quiet zone, and confirm that no border, logo, or fold line crowds the symbol. A careful screen pass catches the errors that are cheapest to fix.
Scanning checks on real devices
A code that scans on one phone can fail on another, so test with at least two phones, ideally one iPhone and one Android device, in the lighting where the table tent will actually be used. Scan the printed proof, not just the screen, because printing changes contrast, edges, and glare. Test at the real distance, with the item held the way a person will hold it, and test a worn or folded copy when the item will be carried or handled. Record which codes passed, which failed, and what was changed after each failure, so the fixes are traceable. If a code fails, treat it as a design problem to solve by adjusting size, contrast, material, or placement, rather than as a scanner problem to ignore. Only approve the full run once the proof scans cleanly on both devices.
Keeping a QA record
A short QA record turns a one-off check into a repeatable process. Note the batch name, the date, the source file version, the number of rows, the proof that was tested, and the names of the people who checked it. List every failure found, what caused it, and what was changed, so the next batch does not repeat the same mistake. Keep the approved proof, or a photograph of it, with the record, because it becomes the reference for comparing the delivered print run. For batches where each code controls access, payment, or identity, keep the record with the batch documentation and retain it for as long as the codes remain in use. When the next run starts, the record tells the team what to check first.
Putting this into practice
Start with a small, real test. Build the batch from a handful of rows, generate the codes, and print them at the exact size and on the exact material you plan to use. Scan each code with two different phones in the lighting where the table tent will live, and confirm that the destination, the printed text, and the layout all match the brief. Fix anything that fails in the source file or the layout, then re-test, because a fix that is not re-tested is only a guess. Once the small test passes, run the full batch from the same checked inputs, and keep the source file, the proof, and the print file together so a reprint uses the same approved version.
Common mistakes to avoid
The most common mistakes in bulk table tents are easy to avoid once they are named. Generating codes from an uncleaned file produces duplicates, broken destinations, and wrong names. Crowding the quiet zone with text, borders, or cut marks makes codes fail even when the print is otherwise good. Printing the full run before testing a proof turns a small fix into a large reprint. Using a long payload on a small table tent makes modules tiny and hard to read. Skipping a second phone test hides failures that only appear on some devices. Review each of these points on the proof copy, and treat any failure as a reason to adjust the file, the size, or the material.
Quick checklist
- Confirm every row has the right destination and a unique identifier where one is needed.
- Keep payloads short and put readable details in the printed text around the code.
- Leave a clear quiet zone on all four sides of every symbol.
- Print a proof at the final size on the final material and scan it on two phones.
- Check the first and last items on every sheet or batch for alignment and drift.
- File the source data, the proof, and the print file together with a dated note.
Related tools and guides
- Generate the batch with the [bulk table tent QR generator](/bulk-table-tent-qr-generator) and check the output before printing.
- Validate every destination with the [QR batch validator](/qr-batch-validator) so broken or duplicate URLs are caught early.
- Package the finished files with the [QR ZIP packager](/qr-zip-packager) so print gets one tidy handoff with a manifest.
- Build the source list with the [bulk generator](/bulk-generator) when the batch starts from pasted rows.
- Size the printed code with the [QR size calculator](/qr-size-calculator) for the real scan distance.
- Test every proof with the [QR scanner](/qr-scanner) on more than one phone.
- Check proofs on paper with the [printed QR tester](/printed-qr-tester) before the full run.
