Our ODL Live vehicle route optimiser engine supports many different constraints, costs and rules which can be configured to solve different sorts of routing problems - e.g. parcel deliveries, scheduling mobile technicians, planning patient transportation, periodic problems etc.

So far, so good… except this leads to another problem, which we haven’t always succeeding in solving as well as I’d like. As we add more options to the engine, it becomes harder for clients to navigate the API, find the rules they need and structure their data accordingly!

So how do we make our API simpler to use, whilst keeping it fully-featured?

We’ve recently added a ‘templates feature’, which lets clients pass data to ODL Live in a simple Excel format that’s tailored to their individual routing problem, containing only the fields they need and named according to their own terminology. We configure the template for the client, and the template converts the client’s own data in an Excel/CSV or flat JSON format to the hierarchical JSON data structures used by ODL Live.

Each client gets their own template based on their requirements. Their template contains all the rules needed for their routing problem (e.g. lateness penalties, clustering parameters, customised job types), hidden neatly away. We expose to the client only the few key fields and parameters they need to know and care about (and give sane defaults to the hidden parameters they don’t need to know). Combined with the route plans Excel exporter, the client just needs to populate and then pull data back from simple Excels. The only fields they need to fill in, are fields they already know and use.

Our aim is to have a solid working MVP integration from Day 1 based on the simplest possible format for exchanging data with the engine, for the client’s own problem. When numbers need adjusting based on feedback from drivers, human planners etc, we just tweak the template and send the client a new version. If the client wants to peek at some of the magic under the hood, it’s there for them to see, but this is totally optional. We keep it simple.

So far this is just for ‘next day’ type problems, where you plan before the start of a drivers shift. Extending this to realtime problems is trickier because you need an event flow (e.g. GPS, proof-of-delivery), but certainly do-able. More to come on that soon.