ENTERPRISE SAAS . PRODUCT TRANSFORMATION

From bespoke enterprise software to a configurable SaaS last-mile platform

The product had originally been built around the operations of one large LPG manufacturer and distributor. When the company decided to offer it to other businesses, the challenge was not simply to make the interface more flexible. We needed to understand which parts of the existing platform represented a repeatable product, which should be configurable, and which capabilities were better left to systems customers already used.

I had worked on the original enterprise platform as well as the SaaS version, so I had seen both the strengths of the existing system and the problems that appeared when we tried to apply it to different organisations.

ROLE.: Lead Product Designer
FOCUS.: Enterprise UX · SaaS transformation · Operational workflows

Circl monitor view on a desktop, with a driver route open on a phone in front of it — The core part of the platform, last-mile planning.

Problem.

One customer’s operating model had become the product

The original platform covered route planning, warehouse operations, inventory, driver workflows, restocking, sales trips and parts of the financial process. It worked for the customer it had been designed for, but over time their internal processes had become embedded in the structure of the product itself.

Features depended heavily on one another, and business rules were often built directly into workflows. Drivers and administrators could be prevented from continuing until another action had been completed elsewhere in the system. For the original customer, this reflected how the business operated. For other companies, the same structure could feel unnecessarily rigid.

When we started talking to other businesses, many already had software for finance, inventory or ordering and had no reason to replace those systems. We needed to separate genuine product needs from behaviour that was specific to one client.

Seven-step timeline of a driver's round before Circl, for gas cylinder delivery, from printed orders to often returning with more than half the load — A driver's day before Circl. Paper orders, a truck loaded from memory, no route, and the phone ringing all day. They sold to restaurants, petrol stations and private homes.

Original admin: a table of active trips with a sidebar listing customers, users, vehicles, containers, stock, trips, assignments, variance, payments and pricing — The old platform. A trips list, and a very long menu.

Original admin trip details page with trip information, a products table, an action history table and an orders table — One old screen with everything on it: products, history, orders and payments.

Map of the original platform's navigation: many top-level areas, each with tabs and forms, annotated with session counts and open questions — I mapped every area, form and tab of the old platform, and checked what people really used.

Research.

Looking at how other companies actually worked

We spoke with potential customers and visited companies in Portugal to understand their day-to-day operations.

The differences between them were operational, not cosmetic. Some planned routes before they knew which drivers were confirmed; others leaned almost entirely on local knowledge, with drivers who knew their areas, customers and likely demand from memory. Deliveries were not always planned in advance either; orders could come through by phone, drivers could make additional stops during the day, and vehicle loads were not always planned against expected demand.

At the same time, many of these companies already had ERP, finance or inventory systems. The gap was more specific. Last-mile planning, vehicle stock and operational visibility were often the areas that were hardest to manage.

The product.

Defining what the product actually was

The original platform contained different kinds of functionality. Some features solved problems we saw repeatedly across customers, some were useful only when a company wanted a particular level of control, and some existed simply because the first customer needed them.

Configurability is not the same as adding more settings. The real decision was what belonged in the core product, what should be configurable, what should stay in the systems customers already ran, and what was legacy complexity that did not need to survive the move at all.

This gave the product much clearer boundaries. Last mile became the core, while everything around it could be added, configured or integrated where needed.

Diagram of the four-part product model: core product, configuration, integrations and optional modules — The resulting product structure. Configuration decides how much control each company wants. The systems they already use stay outside the product, and optional modules plug in only where needed.

Flow diagram titled Before: assign stock to a container, people to a manager, a driver to a vehicle, the vehicle to a trip and the trip to a container, then create the trip, load the vehicle, execute the trip, and return and offload. Red arrows send you back to an earlier step whenever stock, a manager, a driver or an assignment is missing. — Creating a trip depended on several linked assignments and approvals. If something was missing, you couldn't continue.

Planning.

Planning could not be fully automatic

Route planning looked like an obvious candidate for automation, but in practice operators and drivers already had valuable knowledge about customers, areas and how routes actually worked.

The system therefore needed to support both an automatically generated starting point and manual adjustment. Operators could change the order of stops, move work between vehicles, adapt the plan from local knowledge, leave a route unoptimised when that was the right call, and place the jobs the optimiser could not fit.

The goal was not to automate every decision. The goal was to reduce the effort required to create a good plan without removing already useful expertise.

Create plan screen: unscheduled jobs on the left, a map and empty routes on the right — Planning routes based on stock, vehicle capacity and what was due for delivery. Unscheduled work is split in two: jobs ready to be scheduled, and jobs the system could not place because of a constraint, so planners can see what needs them.

Three flow diagrams. Plan creation: filter and select jobs, create a plan, build routes by optimiser or by hand, turn jobs into stops, edit, reoptimise, publish and notify. Add jobs: select an unscheduled job, add it to a route, move the stop, save and publish. Removing jobs: select a stop, check it is allowed, apply changes, and the job returns to the jobs vault. — Imprpoving the flow how to create a plan, Give the user more control and clarity.

STOCK AND CAPACITY.

A stop was not always just a delivery

Planning also depended on what happened at each stop.

A driver might deliver something, collect something, exchange an old item for a new one, or only collect. That meant vehicle capacity changed throughout the day.

A delivery could free up space, while a collection could use it again. Route planning therefore could not be treated purely as a geographical problem. Stock, vehicle capacity, delivery type and route order all needed to work together in the interface.

This was one of the more complex parts of the UX: helping operators understand not only where a vehicle was going, but how its load would change as the route progressed.

Driver app Stop 1 screen with job details, time window and a delivery task with a note about a dog in the garden — The driver sees the job, the task and a note, all in one place.

Stop detail card showing job information and task history beside a map — The stop on the map, with its job and history.

A DIFFERENT KIND OF LAST MILE.

The route still had to work when the day changed

Even after a route had been planned, additional stops could appear during the day. A customer might need something unexpectedly, or a driver might know it made sense to stop somewhere while already nearby.

We therefore designed for a planned structure that still allowed change. Once a route was underway, what had already happened had to stay fixed: failed and partly completed jobs, stops added mid-route and any re-optimisation could reshape the rest of the day without rewriting the part of it that was already done.

The route needed to give drivers and operators a clear starting point without becoming so rigid that normal operational changes broke the workflow.

That principle carried through much of the redesign: make the next action clear, but do not make the process more restrictive than the real operation requires.

A map of London with numbered stops around a depot, beside the CIRCL Driver app listing a route in progress and several scheduled, published routes — The driver can see all routes and stops, and what has been done.

Route summary bar: 50% completed stops, 30 planned, 15 visited, 15 not visited, 7 completed, 3 partially completed, 2 failed, 1 unplanned — The route progress bar shows how many stops have been completed, visited, not visited, failed or unplanned.

Driver experience.

Simplifying the driver experience

The driver experience had different challenges. A single job could hold delivery, pickup and service tasks, and one job could run across more than one stop, so the screen had to make the next action and the current state obvious with very little explanatory copy.

The original mobile workflow contained many checks and dependencies. A driver could be blocked from continuing until another person had completed a step elsewhere in the system.

We focused the mobile experience around the immediate task: where the driver was going, what needed to be delivered or collected, what needed confirmation, and what happened next.

We also reviewed the existing controls more critically, separating checks that were genuinely necessary from those that had simply become part of the original customer’s process.

Driver app Route screen showing a published plan with numbered stops on a map — The driver's day on a map.

Driver app Confirm task screen asking for a photo and a signature — The driver collects a signature and a photo to confirm the delivery.

CONFIGURATION.

Different companies needed different levels of control

The original customer wanted strict rules around stock, route steps, approvals and delivery status. Other companies operated much more informally and gave drivers greater independence. The same split showed up in planning: one company could lean on automatic planning for most of the day, while another built routes by hand and reached for the optimiser only when it actually helped.

Rather than assuming one model was correct, we made the level of control configurable where it genuinely reflected a difference between businesses.

The purpose of configuration was not to expose settings for everything. It was to allow different operating models without creating completely different products.

Circl General settings page: business settings including distance units, working hours and optimisation for time or distance; task settings with default duration and type; proof of work set to required, optional or none for delivery, pick-up and service; and default vehicle locations. — Every company can set up their workflows differently to fit their own operations.

FROM A COMPLETE PLATFORM TO A FOCUSED MVP.

Instead of recreating the entire enterprise platform as SaaS, we focused the MVP on the last-mile problem.

Customers could keep systems that already worked, configure the level of operational control they needed, and add further capabilities only where they were useful. Route planning could combine automation with manual knowledge, while the driver experience could be simplified because it no longer needed to expose the complexity of the wider enterprise platform.

The SaaS version was smaller than the original system, but more adaptable to a broader range of companies.

Circl jobs list with a map of job locations — The planner can view what jobs are available and their details.

Two charts, Monday to Friday: average stops per vehicle against number of vehicles, and actual stops — Learning from the data: average stops per vehicle against number of vehicles, and actual stops.

Outcome.

What changed

Last mile became the main product
We focused on the part of the platform that solved a repeatable problem across customers.
Planning combined automation with human knowledge
Operators could create plans faster while retaining manual control.
Stock, capacity and routes became part of the same UX problem
The interface reflected the fact that deliveries, collections and exchanges changed the vehicle load throughout the day.
The driver experience became simpler
The mobile flow focused on immediate actions rather than exposing the complexity of the wider system.
Control became configurable
Different companies could choose how tightly workflows should be managed.
The new structure became a standalone SaaS MVP

Reflection.

What I took from it

At first, I thought the main challenge would be making the product more configurable. The harder question was deciding what should be part of the product at all.

Some complexity came from the operation itself. Some belonged in configuration. Some belonged in systems customers already had, while other complexity had accumulated simply because the original product had been built around one organisation for a long time.

I also learned that improving an operational product does not always mean replacing the way people already work. Drivers’ local knowledge was valuable, unplanned stops were not necessarily failures of planning, and strict controls made sense for some businesses but not for others.

The design challenge was to understand which parts of the existing process should be improved, which should be preserved, and which should no longer define the product.

Before simplifying the interface, I try to understand where the complexity actually comes from.

Circl web app on a desktop monitor, showing a finished route: a summary of completed, failed and visited stops, a list of stops with their status beside a London map with numbered stops and dotted routes. — A finished route in detail: its stops and their status in a list, with every stop on the map.

NEXT CASE — 02 · THG.

Designing one system for many products, brands and clients

THG component architecture.

Back to home