Development Agency
Contact Sign in Get a project quote

Service

Parcel tracking software development

For courier owners, fulfilment house managers and delivery operators who need consignment tracking designed around their own depots, drivers, carriers and exception rules rather than a generic tracking widget bolted onto a spreadsheet.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A delivery operation that has grown past one van usually tracks parcels in three places at once: the manifest printed at the depot, the drivers' memories and a spreadsheet that customer service updates when someone rings.

  • A recipient calls at four o'clock asking where their parcel is.
  • Customer service rings the driver, who is driving, so the answer is "probably on the van".
  • The consignment was actually sorted to the wrong route at six that morning and is sitting in a cage in the depot; nobody knows until the driver returns at seven.

Where it gets harder

Proof of delivery is a signature on a paper sheet that gets photographed at the end of the week, if at all.

  • When a shipper disputes a delivery, the operations manager searches through photos on a shared phone.
  • Exceptions are handled by whoever picked up the call: a card through the door with no record, a redelivery promised for a day the route does not run, a parcel returned to the shipper without anyone telling the recipient.
  • Third-party carrier consignments are tracked by copying tracking numbers into each carrier website in turn.
  • Shippers email spreadsheets of consignments that are keyed in by hand, with the typing errors that implies.
  • By the time a performance report is wanted, the data to build it has never been captured.

Scope of the service

What the build covers

A custom parcel tracking build normally covers the consignment lifecycle from creation to closure:

  • Consignment records with your own tracking number format Shipper, recipient, service level and piece count
  • Scan events for collected Received at depot, sorted to route, out for delivery, delivered and exception, each stamped with driver, time and location
  • A driver scan page That works on an ordinary phone with photo and signature proof of delivery
  • A public tracking page That shows the recipient the status without exposing the shipper's data
  • Notifications on each status by SMS or email with wording you control
  • An exception queue where card-left Address not found, refused and damaged consignments wait for customer service to book a redelivery, a return or a collection from the depot
  • Bulk import of consignments from shipper files
  • Shipper accounts with their own view
  • Delivery performance reports by route Driver, shipper and service level

How discovery works

Discovery walks through one day at your depot: how consignments arrive, how they are sorted to routes, what the driver does at the door when nobody answers, how a redelivery is booked and who tells the recipient, how third-party carrier parcels are followed, and what the shipper actually wants to see. Each becomes a named stage in the scope document: created, collected, at depot, on route, delivered, exception, closed.

Deliberately out of scope

  • Route optimisation, vehicle telematics and driver payroll, which stay in the tools built for them and are connected where it pays

When the scope grows

Scoping scenario

A regional courier with two depots, thirty own drivers and overflow to two national carriers wants one tracking number per consignment whatever network carries it, carrier status events mapped into its own scan vocabulary, an exception queue shared across both depots, and shipper logins with bulk import and a monthly performance report. That is a materially different build from a single-depot operator with eight vans, and the scope document says which is being built.

Deliverables

What you receive

  • Discovery notes from a walk-through of a depot day, from inbound sort to the last proof of delivery
  • A written scope document naming each consignment stage and exception type, with what is out of scope
  • Design of the driver scan page, the exception queue and the public tracking page, checked on the handsets drivers carry
  • The build, deployed to your hosting or ours
  • Migration of open consignments and shipper records from current spreadsheets or carrier exports, where relevant
  • Training for operations, drivers and customer service, with a one-page guide for the exception queue
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access, contacts, sample manifests and shipper files, and a look at how scans, proof of delivery and carrier parcels are handled today.

    Project stage: Onboarding

  2. Planning

    Discovery with the operations manager, a senior driver and customer service; the scope document and milestone plan are agreed.

    Project stage: Planning

  3. Design

    Clickable designs of the driver scan page, the exception queue and the tracking page, checked on the actual handsets and a depot screen.

    Project stage: Design

  4. Development

    Built in stages: consignments and scan events first, then driver page and proof of delivery, then notifications, exceptions, imports and carrier feeds.

    Project stage: Development

  5. Client review

    Two drivers run a real route with test consignments alongside the paper sheet and tell us where the scans, photos or exception types do not fit.

    Project stage: Client review

  6. Revisions

    Scan vocabulary, exception rules, notification wording and report columns are adjusted from the review and re-checked against the scope.

    Project stage: Revisions

  7. Ready for launch

    Open consignments migrated, shipper imports tested on real files, notifications sent to numbers you control, carrier feeds checked, launch checklist signed off.

    Project stage: Ready for launch

  8. Delivered

    The operation runs on the new system; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Carrier tracking and label APIs for consignments handed to third-party networks
  • SMS and email providers for status notifications to recipients and shippers
  • Label and thermal printers at the depot and in shipper accounts
  • Address lookup and mapping services for validation and depot routing
  • Shop and order management systems that create consignments automatically
  • Accounting software for shipper invoicing from delivered consignment counts

How we would approach it

Worked example

Concept demo

A two-depot courier with national carrier overflow

The situation

A courier running its own vans from two depots hands anything outside its area to two national carriers, and wanted its shippers to see one tracking number and one status language whatever network carried the parcel.

Why it is a custom build

This needs a custom build rather than a tracking widget because the central object is the mapping between three different status languages and the operator's own, and the exception queue has to work identically whether the failed attempt was made by an own driver or by a carrier.

The scope we would propose

  • A consignment record that holds its own tracking number plus the carrier reference when one exists
  • Carrier status events pulled from each carrier feed and mapped into the same scan vocabulary used by own drivers
  • A single exception queue across both depots with ownership assigned by depot
  • Shipper logins that import a consignment file in the morning and see delivered-with-proof counts by evening
  • A monthly report of first-attempt delivery rate by route and carrier

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of depots and whether exceptions are handled centrally or per depot
  • Own drivers, third-party carriers or both, and how many carrier feeds must be mapped
  • Proof of delivery requirements: photo, signature, what-three-words location or a combination
  • Notification channels and how many status points trigger a message
  • Shipper accounts, bulk import formats and whether shippers print labels themselves
  • Volume of open consignments and shipper records to migrate
  • Custom performance reports beyond the standard route and driver views
  • Hosting choice: your own hosting or ours

Start from a package

Parcel tracking package

Consignment tracking with scan events, a phone-based driver scan page, photo and signature proof of delivery, recipient notifications, an exception queue for failed deliveries and shipper imports.

Custom build
View the package

FAQ

Frequently asked questions

Would the package cover us, or do we need a custom build?

A single-depot operator with its own drivers, standard scan events and one notification channel is usually covered by the parcel tracking package through configuration. Mapping several carrier feeds, multi-depot exception ownership or a shipper-facing import with label printing is where the custom route becomes the honest recommendation. Discovery is where we say which.

Can recipients track without seeing shipper details?

Yes. The public tracking page shows status, the next step and proof of delivery once delivered, and nothing about the shipper account, the driver or other consignments on the route. What each audience sees is decided in the scope document.

How do third-party carrier parcels appear?

Where a carrier offers a status feed, their events are pulled in and mapped to your own scan vocabulary so the recipient sees the same language. Where a carrier offers nothing, customer service records the status by hand against the consignment. The scope names which carriers are connected.

What happens with proof of delivery photos?

The driver page captures a photo, a signature or both, with time and location, and stores them against the consignment. Retention and who can view them are set with you, since photographs of doorsteps are personal data under UK data protection law.

Who owns the system afterwards?

You do. The source code, consignment history and proof of delivery records are handed over at delivery and can be exported at any time. Hosting and maintenance are optional and separately agreed.

Get a project quote for parcel tracking software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences