Parcel shipping software: labels, service choice and manifesting

Service selection is a rule set, not a preference

The choice of carrier and service depends on destination, weight and dimensions, declared value, delivery promise made to the customer, goods restrictions, and available capacity that day. Rules can favour cost, promised date or carrier balance, and they need a deterministic fallback when the preferred option is unavailable. What matters operationally is that the rule is applied at packing without the operator deciding, and that the reason for the choice is recorded, because carrier mix analysis and cost allocation both depend on knowing why each parcel went where it did.

Labels are carrier specifications, and they change

Each carrier defines its own label content, barcode symbology, data encoding and print quality expectations, and a non-compliant label is either surcharged or refused at the depot. Specifications change with network reconfigurations, and changes arrive with modest notice. This is the recurring maintenance cost of multi-carrier despatch and the strongest argument for buying rather than building: the supplier absorbs the specification churn across its customer base. Whoever owns it needs a test process that verifies real printed output rather than a rendered preview.

Cross-border parcels need customs data at packing

A parcel crossing a frontier needs item descriptions, classification, origin, value and the identity of the parties, and administrations have moved towards requiring electronic advance data on consignments before arrival. That data has to exist at the moment the label is produced, which means product master data must carry classification and origin rather than someone typing a description into a despatch screen. Specific data requirements, thresholds and simplified procedures differ by destination, so confirm them with the receiving country's customs administration.

Manifesting closes the day

At cut-off the system transmits a manifest of what each carrier is collecting, which is what makes parcels visible in the carrier's network and what the collection is checked against. Discrepancies between manifested and physically loaded parcels are a persistent source of lost items and billing disputes, so reconciling the two before the vehicle leaves is worth the few minutes it costs. Late-processed parcels that miss the manifest cut-off should be held to the next despatch deliberately rather than sent unmanifested.

Tracking, exceptions and the returns label

After despatch the same system usually ingests carrier tracking events and surfaces them to customer service or to the shopper. It also generates returns labels, which raises a design decision: pre-printed labels in the box are convenient and encourage returns, while on-demand labels issued through an authorisation give control over routeing and volume. Either way, outbound and return parcels should be linked to the same order so that a customer enquiry does not require two searches.

Frequently asked questions

Is a carrier's own despatch tool sufficient?

It works while there is one carrier and volumes are modest. Two or more carriers means duplicate data entry, no unified tracking and no rule-based selection, which is normally the point at which multi-carrier software pays for itself.

Should carrier selection consider cost per parcel?

It can, but only if rated cost is available at packing and the promise made to the customer is respected. Optimising purely on price while ignoring the promised date produces savings in transport and losses in service recovery.

What causes despatch to stop at peak?

Most often a carrier interface failing under load or a label specification change deployed without testing. Both are mitigated by a documented fallback carrier, cached rating, and the ability to print a compliant label without a live call for the highest-volume services.