Service

Courier ordering software development

For owners of local and urgent courier companies who want job booking, pricing, dispatch and account invoicing designed around their own vehicles, service levels and controllers rather than a generic delivery app that assumes every job is a parcel in a car.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A courier company with a dozen drivers usually takes jobs by phone and email, prices them from a controller's head, writes them on a dispatch sheet or a whiteboard and texts the driver.

It works while the controller who knows the prices is in the room.
A regular account customer emails a job for a pallet from an industrial estate to a hospital by two o'clock; the controller quotes a van rate from memory, the driver sent is in a small van, and the pallet does not fit.
A new customer rings for a motorbike job across town, is told a price, books it, and the invoice three weeks later says something different because nobody wrote the first figure down.

Where it gets harder

Multi-drop jobs are the worst: five drops in a single booking become five lines on the sheet, one is missed, and the driver drives past the missed address twice.

Proof of delivery is a name on a docket that reaches the office on Friday.
Account customers ask for a monthly statement broken down by their own cost centres and get a pile of dockets instead.
Timed jobs with a collection window and a delivery deadline are tracked by the controller glancing at the clock.
When the controller is off, the business runs on guesswork.

Scope of the service

What the build covers

A custom courier ordering build normally covers the job from booking to invoice:

An online booking form with pick-up and drop-off addresses Parcel or load details, a vehicle type from your fleet such as bike, small van, large van or luton, and a service level you define such as timed, urgent or economy
Price rules you own Combining distance, urgency, vehicle type, waiting time and out-of-hours uplifts, so the quoted price is the invoiced price
Multi-drop jobs with ordered stops
A dispatcher board showing unassigned Assigned, collected and delivered jobs with drivers and their current job
A driver page on a phone with the job list Navigation hand-off, status taps and proof of delivery
Customer notifications at collection and delivery
Business accounts with cost centres References and monthly invoicing
Ad hoc card payment for one-off customers

How discovery works

Discovery works through a controller's shift with you: how a job is priced today, which vehicle types and service levels you actually sell, whether drivers are employed or owner-drivers paid per job, how waiting time and failed collections are charged, whether jobs are assigned by the controller or offered to drivers, and what account customers need on their invoice. Each answer becomes a named stage in the scope document: booked, priced, dispatched, collected, delivered, invoiced.

Deliberately out of scope

Route optimisation across the whole fleet, vehicle telematics, driver payroll and fuel cards, which stay in their own tools and are connected where the connection earns its place

When the scope grows

Scoping scenario

A courier with two bases and forty owner-drivers wants jobs offered to drivers by vehicle type and proximity with the controller able to override, owner-driver self-billing statements per month, account customers with cost-centre references and purchase-order numbers on every invoice, and a client-facing API so two large accounts can post jobs from their own systems. That is a materially different build from a six-van firm wanting online booking and a board, and the scope document says which one is being built.

Deliverables

What you receive

Discovery notes from a walk-through of a controller shift, from the first booking to the end-of-day docket pile
A written scope document naming each job stage, vehicle type and service level, with what is out of scope
Design of the booking form, the dispatcher board and the driver page, checked on the phones your drivers carry
The build, deployed to your hosting or ours
Migration of account customers, addresses and price tables from current spreadsheets, where relevant
Training for controllers, drivers and the accounts person, with a one-page guide for the board
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.

Onboarding

Access, contacts, your current price sheets, dispatch sheet and invoice layout, and a look at how drivers receive jobs today.
Project stage: Onboarding
Planning

Discovery with the owner, the lead controller and a driver; the scope document and milestone plan are agreed.
Project stage: Planning
Design

Clickable designs of the booking form, the dispatcher board and the driver page, checked on a controller screen and a driver handset.
Project stage: Design
Development

Built in stages: accounts, vehicles and price rules first, then booking and the board, then the driver page, proof of delivery and invoicing.
Project stage: Development
Client review

Controllers run a test day with real jobs keyed in parallel and tell us where prices, statuses or the board do not match the shift.
Project stage: Client review
Revisions

Price rules, vehicle types, board columns and invoice layout are adjusted from the review and re-checked against the scope.
Project stage: Revisions
Ready for launch

Accounts and price tables migrated, card payments and notifications tested, driver phones set up, launch checklist signed off.
Project stage: Ready for launch
Delivered

The firm books and dispatches 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.

Card payment providers for one-off bookings and account top-ups
Accounting software for monthly account invoices and owner-driver self-billing
Mapping and distance services for pricing and driver navigation hand-off
SMS and email providers for booking confirmations and delivery notifications
Vehicle telematics for live driver positions on the board
Customer order systems that post jobs through an API

How we would approach it

Worked example

Concept demo

A two-base courier with owner-drivers and account customers

The situation

A courier company running forty owner-drivers from two bases wanted to stop pricing from memory and stop retyping jobs from account customer emails.

Why it is a custom build

This needs a custom build rather than a delivery app because the price rules, the two bases and the owner-driver statements are the core of the business, and the API for account customers has to reflect exactly the vehicle types and service levels the firm sells.

The scope we would propose

A price matrix owned by the firm combining distance band, vehicle type and service level with waiting time and out-of-hours uplifts
Booking by phone, web form or an API that two large accounts post into from their own systems
A dispatcher board per base with a shared view, where jobs are offered to nearby drivers of the right vehicle type and the controller can override
A driver page with status taps and photo proof of delivery
Month-end runs that produce account invoices with cost-centre references and owner-driver self-billing statements from the same job data

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 bases and whether controllers share one board
Complexity of the price rules: distance bands, vehicle types, service levels, waiting and out-of-hours uplifts
Employed drivers, owner-drivers or both, and whether self-billing statements are needed
Controller assignment, offers to drivers, or automatic assignment by proximity
Multi-drop jobs and how stops are priced
Account customer invoicing with cost centres, references and purchase orders
An API or portal for account customers to post jobs
Hosting choice: your own hosting or ours

FAQ

Frequently asked questions

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

A single-base courier with a few vehicle types, distance-based pricing, a controller board and monthly account invoices is usually covered by the courier booking package through configuration. Multi-base dispatch, owner-driver self-billing, a customer API or unusual price rules are where the custom route becomes the honest recommendation. Discovery is where we tell you which.

Can we keep our own pricing?

Yes, that is the point. The price rules are yours: distance bands, vehicle types, service levels, waiting time and uplifts are entered by you and changed by you. The system applies them consistently so the quoted price and the invoiced price are the same figure.

How are jobs given to drivers?

Three patterns are common: the controller assigns from the board, jobs are offered to drivers of the right vehicle type near the pick-up and the first to accept takes it, or a mix where offers go out and the controller overrides. Discovery decides which, and the build can support more than one by service level.

Can account customers book without ringing?

Yes. Account customers get a login to book, see job status and download invoices. Where a customer has its own order system, an API lets it post jobs directly, which is scoped as custom work.

Who owns the system afterwards?

You do. The source code, job history, price rules and account 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 courier orders 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

Courier ordering software development

What goes wrong today

What the build covers

How discovery works

Deliberately out of scope

When the scope grows

What you receive

How a project runs

Onboarding

Planning

Design

Development

Client review

Revisions

Ready for launch

Delivered