How a booking portal paid for itself

Customer portals sound like something only large companies can afford. This article walks through one of our example projects, a booking portal for a mid-size logistics company, to show how the numbers work for a business with around 80 employees. The figures are illustrative, but the structure is exactly how we build a business case with clients.

Customers booked pickups by phone and email. Four planners spent roughly half of each morning reading emails, retyping orders into the transport management system and answering "where is my shipment?" calls. On top of that, around five pickups per week failed because of wrong addresses or time slots.

We sat down with the operations lead and put rough numbers on the current situation:

• Retyping and answering status questions: about 20 planner hours per week
• Failed pickups: five per week, each costing a wasted trip and a rebooking
• Errors in invoicing caused by manual entry: a few hours of correction work each month

Added up, the manual process cost somewhere around 60,000 euros per year, before counting the effect on customer satisfaction.

The first release was deliberately small:

• Customer login with company accounts and user roles
• Booking form with address lookup and validation of available time slots
• Live shipment status, pulled from the transport system
• Download of delivery notes and invoices
• An exceptions dashboard for planners

Everything else, like quotes, claims and API access for large customers, went on the list for later.

The blueprint week, ten weeks of build and the rollout came to a total in the mid-five figures. Hosting and a support plan add a few hundred euros per month.

Within three months, most bookings came through the portal. Planner time spent on retyping and status calls dropped by about 70 percent. Failed pickups fell by almost half, because addresses and time slots were checked at the moment of booking. Based on those numbers, the portal earned back its build cost in less than a year.

Looking back, three decisions mattered most:

• Starting with the most painful workflow, not the full wish list.
• A two-week pilot with ten friendly customers before the wider rollout.
• Treating the planners as users too, not just the customers.

If your team spends hours per week on requests that customers could handle themselves, write down the time and the cost of errors. That number is the budget you are already spending. The question is only whether you want to keep spending it on manual work, or once on a tool that does it for you.