Label printing looks like a solved problem right up until the day a customer scans one of your cartons and the code doesn't read. Then it becomes a real project, usually under deadline, usually with a chargeback attached.
Most of the trouble traces back to a single assumption: that a printer plus any label software adds up to a labeling system. The printer is the easy part.
Printing a label and printing a barcode are different jobs
The software that prints address labels for invoices and mailings does one thing well, which is putting text on a template at a fixed size. Barcode labeling is a different product category, and the difference isn't cosmetic.
A barcode label has to encode data in a symbology the receiving party can scan, at a size and print quality that survives handling, with the values pulled from a live record rather than typed. Software that can draw a barcode image is not the same as software that can produce a scannable one at production speed with the right data on it.
Where does the data on the label come from?
This is the question that matters most and it's usually the one asked last.
If somebody types the part number, quantity and order number into a label template, you've added a second data entry step to a process that already had one. Anything typed can be typed wrong, and a wrong label is worse than no label, because it looks authoritative to everyone downstream.
Label software that reads directly from your item master and your open orders removes that step. The label reflects what the record says at the moment of printing. Once lot numbers, expiration dates or serial numbers belong on the label, this stops being a convenience and becomes the only workable option, because those values change per unit and nobody keeps up by hand.
Ask specifically which fields it can pull, from which records, and what the label does when a value is missing. A template that silently prints a blank where a lot number should go is a problem you'll discover at somebody else's dock.
Will the barcode still scan when it gets there?
Three things decide this, and none of them are really software features, which is why they get skipped.
Print method. Direct thermal labels darken under heat and fade with sunlight and abrasion. They're fine for a shipping label that gets scanned within a few days. Thermal transfer, which uses a ribbon, holds up in a freezer, in a yard, and on a carton that sits in a rack for a year. Choosing the wrong one is how a label that printed perfectly becomes unreadable at the destination.
Resolution. A 203 dpi printer is enough for a standard linear barcode at normal size. Small labels, tight spaces and 2D codes like Data Matrix generally need 300 dpi to hold their shape.
How the software talks to the printer. Sending native printer commands is faster than rendering each label as an image through a generic driver, and the difference shows up when you're printing a few hundred labels for a wave rather than one at a time.
Where the labels actually print
One labeling station is easy to supervise and easy to turn into a queue. If pickers and packers have to walk to a single printer, you've built a bottleneck into the middle of fulfillment, and the workaround people invent is worse than the wait: somebody prints a stack of labels for several orders at once, carries them back, and they get applied to the wrong cartons.
Printing at the point of use avoids that. A printer at each pack station, or a mobile printer on a cart for receiving and putaway labels, means the label is produced where the product is and applied immediately.
There's also the failure case to plan for. If every label in the building comes off one printer, that printer breaking stops shipping. A second unit that can take over is cheap next to a day of held orders.
Ask how the software is licensed, per printer or per station or per site, because that determines whether adding a printer later is a decision or a negotiation.
Labels your customers specify
Retail, grocery and automotive customers routinely dictate the carton label down to the symbology, the data fields, the placement and the label size. Getting it wrong means a chargeback rather than a conversation.
Before you choose software, collect the routing guides from your largest customers and check that the formats they require already exist as templates. Building a compliant carton label from scratch is possible in most tools, and it isn't a project you want to discover after purchase.
Mobile and off-site printing
If sales or field service staff need to produce labels away from the building, treat that as a separate requirement rather than a variation on the same one. It usually means a portable printer paired to a phone or tablet, and the software has to reach your data over a cellular connection. Confirm what happens when that connection drops partway through a job.
Hardware fit
The scanning side deserves the same check as the printing side. A device used all day on a warehouse floor has to survive a drop onto concrete and needs a battery that lasts a full shift. A device used in a freezer needs to be rated for it. Confirm the software supports the specific models you intend to buy rather than the category they belong to.
The short version
Six questions worth asking any vendor:
- Which fields can the label pull from our system, and from which records?
- What does the label do when a required field is empty?
- Does it drive our printers natively or through a generic driver?
- Can we print at each pack station, and how is that licensed?
- Which customer carton formats ship as standard templates?
- What does the label look like after a month in a freezer?
The last one you have to test rather than ask.
