Metro Express

Cogent Team:
1 designer, 1 developer, 1 product manager

Project Timeframe:
6 weeks

About Metro Express

This leading logistics company have one of the largest fleets of on-demand crane trucks in Queensland, New South Wales, Victoria and South Australia. They deliver heavy vehicles and machinery, rather than the usual boxes and packages. For example, they use semi trailers, 16 tonne crane trucks and concrete trucks to deliver steel work and building materials for 30 storey buildings under construction. In a nutshell, really big stuff.


After using third party logistics management software for a long time, the senior leadership team came to us wanting to explore what a custom solution would look like. They needed features like GPS tracking, real time updates, and ease of use for all their team members. The third-party solution they were using did these things, but in a really difficult and clunky way. 

After being referred to Cogent by our friends at Shebah, the team came to us with the question: “How much will it cost us to move away from our existing software provider and still have the exact same feature set, plus anything else that we want to build on top of that?”


Logistics companies have a lot of stakeholders to consider, which made this project a more complicated Clarify than usual. There are drivers, fleet managers, dispatch controllers, clients and many more complicated relationships to consider.

As with everything at Cogent, a cross-functional team consisting of a designer, a product manager and a software engineer gathered around the problem. Firstly, we dived deep to understand the commercial opportunities and challenges of the problem.

This initial session involved all of the key stakeholders in the room to do a lot of really complicated user journey mapping. For example, if a client calls and needs a 16-tonne crane truck delivered tomorrow, what’s the process there? Who’s involved? Who answers that call? When and how is the driver and equipment assigned? We mapped this out, all the way through to how do they bill the client, once the delivery is made. When do they bill? How do accounts get paid? How does the bank sync with all of that? 

Rather than simply taking these user journey maps and the existing third-party solution as gospel to quote how much a custom solution would be, we then did extensive research into the actual needs of all the stakeholders involved. This important step is often where the ‘theory’ of how something ‘should’ work, diverges from what happens in real life. It’s also often where the biggest savings in solution-scoping can be made. 

It’s one thing to say A happens, then B, then C. It’s another thing to then test this in action.

Our research included activities like interviewing their clients about what they expect and what their biggest challenges are, and a designer doing 5am runs with truck drivers to get a full picture of what it’s like to be on the road. For example, we discovered challenges like using GPS mapping in situations where drivers are required to deliver equipment to areas that don’t exist on Google Maps yet, and the requirement to use mobiles in often dangerous construction zones.

We then collated this research and recreated the user journey maps to validate or challenge what was previously assumed.

The final piece was a deep tech investigation into what investment would be required to create the technical architecture needed, the data transfer, and of course the estimated cost of building the software itself.


Part of the solution process were a series of collaborative sketching sessions with the entire team, including the client and potential users of the system, to explore some really key business problems that were uncovered as part of the research. 

Following this, we proposed a solution through a series of screens created by the designer to paint a vision of what the solution could look like. 

Once everyone was on the same page, we began scoping what this custom solution would be likely to cost. This involved considerations like “How are we going to solve the problem that some truck drivers have iPads and some have mobiles? Will it be cheaper for the client to get us to build a responsive solution, or should they just buy 50 more mobiles and we build an native app?”

This scope was presented back to the senior leadership team, who by that point really understood what their challenges were and all the requirements they had. 

In the end, they decided not to go ahead with building this custom solution. And you know what? That’s completely fine.This is the whole point of why we encourage businesses to do a Clarify – one option is to spend endless amounts of money building something without understanding what you’re getting yourself into, the other option is that you can explore whether it’s an investment you really want to make and potentially save a lot in the long run.

Share This Case Study

Share on facebook
Share on google
Share on twitter
Share on linkedin