Designing the columns
A good CSV for bulk feedback cards has one row per feedback card and one column per fact the batch needs. Start with the columns that drive the code and the label, such as location name, feedback form URL, card filename, and short prompt. Add a column for the output filename so every generated file gets a predictable name that maps back to its row. Keep header names short, plain, and free of special characters, because header names often become part of the workflow. Avoid extra columns that nobody uses, since unused columns invite inconsistent data, and avoid putting two facts in one cell, such as a name and a phone number together, because that makes validation and layout much harder. If a field is optional, leave it blank rather than writing placeholder text that could end up printed on the feedback card.
Cleaning the data before import
Cleaning is where most bulk batches are won or lost. Trim extra spaces at the start and end of every field, and normalise capitalisation so names and titles look consistent on the printed items. Check every URL by opening it, not by reading it, because a single mistyped character sends scanners to the wrong page or to an error. Look for duplicate rows, because a duplicate row becomes a duplicate code, and confirm that identifiers such as reference numbers are unique across the file. Replace missing values with the correct destination or remove the row, rather than leaving a blank that generates a broken code. Save the cleaned file as a new version, so the original export stays untouched and the changes can be reviewed.
Testing the file with a small sample
Never generate the full batch from an untested file. Copy five to ten rows that cover the hardest cases, including the longest names, the longest URLs, and any field with commas, accents, or quotes, and generate codes from that sample only. Print the sample at the final size, scan each code, and compare the scanned destination with the row it came from. Check that commas inside quoted fields did not split a field into two, and that accented characters survived the export without turning into replacement symbols. If the sample fails, fix the source file and re-test, because the same error will appear across the full batch. Once the sample passes, generate the full batch from the same cleaned file, and keep the file as the record of what was produced.
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 feedback card 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 feedback cards 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 feedback card 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 feedback QR generator](/bulk-feedback-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.
