This article aims to broadly cover how Gophr works, by explaining how the system chooses and finds vehicles in real-time.
If you were going to build a platform solution to manage and balance same-day logistics customer demand vs courier supply and do it automatically and in real-time, how would you go about it?
Throughout 2013 and 2014 we started by looking at both sides of the equation and their desire for how work should be handled. We then listed those out in terms of priority. This is not to say that everyone’s priorities on each side of the customer/courier divide were the same but they nonetheless broadly broke down like this:
- Ensure the item is handled and transported safely
- The item gets there at the time specified
- That the price is fair
- There’s total oversight over the delivery process (tired of not knowing where stuff is and getting spurious charges)
- Good courier to deal with (generally means likeable and presentable)
- Flexibility in approach should changes need to be made
- Courier jobs should pay in accordance with the level of time and/or work being asked
- Item is suitable for vehicle
- Job is convenient (meaning you shouldn’t have to pick something up in Glasgow if you live in London)
- All the information needed to complete the job quickly and successfully, should be provided
- Customers are nice to deal with
Once you understand both sides motives you can then move into the thinking about how the platform should work and informational building blocks which will enable you to pull it off.
These informational building blocks become ever more important as the platform scales; the higher the accuracy of the information going in, then the greater the overall efficiency produced overall.
With logistics the devil is in the details. And these details shouldn’t just help to build the most efficient platform, but will also go a hell of a long way towards future proofing it.
Broadly speaking (and for the sake of brevity!) the details needed on supply and demand side are as follows:
- Location (Pick up and delivery)
- Contact information (for pick up and delivery)
- Timing (Pick up and delivery)
- Consignment information (Size, weight, characteristics of item, number of items)
Whether you are sending a bank card, a 3 piece-suite, or a fleet of cars on the back of a HGV these variables will broadly stay the same.
- Information on driver (includes credentials)
- Information on vehicle (capacity is key)
- Direction of travel
- Status of each jobs
- ETA’s for all stops relating to jobs
- Load capacity status relating to jobs (current and future)
Now, the one big thing that’s missing here compared to how most traditional courier companies operate when dealing with the customers is: “what type of vehicle are you looking to do this job?”. In the traditional courier space the vehicle drives the price, followed by the pick up and delivery location.
This approach has always made sense because it was far too difficult to try and price individual items when customers booked jobs over phone, and exacerbated by the fact that courier companies couldn’t really police what was actually being sent. Since the advent of mobile phone cameras clearly this is now less of an issue. It’s far easier to provide instant photographic evidence that the item the customer said was only the size of 24 pack of beers is actually much closer to the size of large Canadian moose.
Putting aside a 1200kg moose, it makes sense that couriers should be paid more to carry a box weighing 50kg into their vans than a similarly sized box that weighs a fraction of that – the 50kg box is more work to carry and is more likely to put your back out.
This kind of thinking is accepted wisdom in air freight where the weight and dimensions of consignments is absolutely crucial to managing work. Barring a few exceptions, that thinking hasn’t quite made its way back down into road freight.
The truth is, as long as whatever vehicle is sent is suitable to meet the customers idea of what should happen (and is as environmentally friendly as possible) asking them the type of vehicle they want should actually be pretty irrelevant.
This became very clear to us in our early customer research when we found huge amounts of people booking motorcycles to send envelopes less than 2 miles away. The assumption being made by those customers was that motorcycles are faster and should therefore get there quicker. The truth is that over those kinds of distances a cycle courier will generally trounce a motorcyclist for pace over those distances and beyond. If you’ve ever seen a professional cycle courier at work (I use the word ‘professional’ here to clearly separate them from students on bicycles delivering food) this should come as no surprise.
This kind of thinking directly affected how our booking engine was designed: customers enter the pick up and delivery location for the job they want. The characteristics of the item then need to be defined, at which point they are provided with a list of suitable vehicles with the fastest, cheapest and most environmentally friendly automatically preferred. They are still free to change to whatever they wish.
Once requested the Gophr system then scans all the available active couriers that are suitable for the job, prioritising those that are close by and travelling in the same direction. It does this by looking at their existing pick up and delivery locations (including ETA’s and deadlines) as well as their current and future capacity. The idea being that if there’s any risk a courier won’t be able to complete the job to the customers specific requirements then the courier will not be sent the job notification.
There are many other factors that come into play for this fraction of a second calculation to take place – needing to take into account whether one courier is busier that is further away, or reducing the time a customer may need for the item to be picked up are just two examples – but broadly speaking this is how it works.
The key here is direction of travel and capacity. We’ve been doing it for over 3 years and it will always be a work in progress however we feel that this logic allied with our API and with all the other elements we’ve built are putting us in a very strong position to deliver some game-changing innovations going forward.
We’ll share those when the time comes 😉