OnGo Fleet by VanOnGo is a product that allows any business within our system to start the delivery process. How it can be done and what benefits the client gets - further in the article.
How did you come up with the idea to create OnGo Fleet?
The idea arose on the basis of communication between the Service Execution and Sales teams, who did a market analysis and found that the demand for such software is significant in the market, but at the same time there is still no easy-to-use, convenient and functional software that allows you to manage your fleet. We realized that we can do it: successfully enter the market and cover more consumer needs. So the product was born to give fleets more customers and VanOnGo more users.
How is it different from other VanOnGo products?
Our other products are software that builds routes, where you can manage drivers, add orders and so on, but this software cannot be accessed by an employee of another company, that is, he does not have a personal account. This is the first thing. Secondly, in other products, there was no possibility to add drivers. That is, our entire product was made for the fact that we have a Service Execution group that fully controls the product from the inside: searches for drivers, creates requests in the system, searches for cars, pays salaries and so on. In short, it is engaged in operational work. And OnGo Fleet allows us not only to automate delivery services and transparently build routes, but also, in principle, to sell the software as a ready-made product, which has tutorials, a personal account as well as an API in which you can do everything yourself.
You can create driver profiles, add their cars, specify the level of driver salaries and delivery costs for certain orders. In other words, OnGo Fleet is a product that allows any business within our system to start the delivery process.
What are the main features of OnGo Fleet?
The product is designed to equalize supply and demand for drivers in the market. What do I mean? There are companies that have drivers but do not have enough orders. This is the first segment. The second segment is companies that have orders but no drivers. And the third segment is companies where there are orders from time to time and there are drivers who "sit" for half a day due to a few orders. If we combine all three segments into one, we can help companies to equalize the load of drivers. In other words, OnGo Fleet aligns the supply and demand of drivers in the market, and by aligning this supply and demand, it turns out that we cover all cases of orders optimally.
And, as I understand, it is possible to do all this yourself after the acquisition of OnGo Fleet?
Yes, we help with the launch of the product, we help with integration and the first launches, the first trips, and then we give instructions and all the tutorials with which the owner of the fleet can manage the product himself.
And who can be the owner of a fleet?
The owner of a fleet can be both a service that has its deliveries and a service that has only cars. We can help them “meet” and cooperate to the benefit of everyone. That is, a company with a fleet of cars will see a company that has many orders for delivery, and they will cover each other's requirements. In this way, on the one hand, orders for drivers will be guaranteed, on the other hand, deliveries will be made, and in fact, confidence that this process will be stable.
So, any driver, any fleet, what we call a fleet, can join anywhere, are there any specific operational areas where they can join?
Of course, they will need to sign an agreement first. In general, we will control the zones to avoid the case when there are drivers but no orders yet.
How quickly, and easily can fleets integrate into our system? How quickly, and easily can they receive orders and report on their fulfilment?
There are two integration scenarios. The first is simple—through the interface. That is, a fleet owner can add his drivers, cars, everything through the interface, without the help of developers or anyone else from the technical side. The second option involves API integration, where there will be a separate block in the API for OnGo Fleet, created specifically for large fleets.
For example, if a fleet is 10 cars and 20 drivers who drive these cars on different days, then one can effortlessly manage everything manually and a person who has a small business, a small fleet, does not need to hire additional developers for this. But if the fleet has 1000 cars, it will be very difficult to add them manually. For this, there will be an API where you can dynamically create 1000 drivers, 1000 cars, link them, or, for example, update the schedule of drivers and so on.
There are 2 scenarios here, and after the experience we had with our control panel and our integrations, we realized that in order for the product to develop, there must be two ways to integrate with it. The first is simple, for those who have a small business and no developers, or developers do not have time. And the second is complex, for large corporations that have large volumes and then API integration is their option.
But the functionality of the product will be basically the same?
Yes, the functionality of the platform, which they can fully use, will be the same, no matter how they joined.
Usually, business clients ask how we verify these fleets.
In the future, there is an idea for Ukraine to integrate with the Diia app. There is an open API in the Diia application, where you can integrate and, accordingly, check the person's data, understand who you are dealing with. In Poland, for example, there is also such software. So, I think, in the near future, we will integrate with state software so that the verification of drivers is automatic. In addition, our system can add documents: scan a passport, add a contract, etc.
And there is one more case — the Rate us functionality.
We all understand that when we fight for the quality of the fleet, we can do such alpha-beta testing of this fleet. For example, ask drivers to deliver on a test basis for a week, and the client will receive a link from rate us, or he will see it in the application, and thus evaluate the quality of delivery. That is, the way products test the product through hypotheses and market analysis is also possible to test the fleet.
How do we motivate drivers with the product? Is it only the number of orders they can fulfil and thus earn money, or something else?
Firstly, our product is convenient and greatly simplifies the life of a conditional driver: all his orders are concentrated in one application, and he does not need to “run” between different systems (as it happens with drivers in competing taxi services). Our application is comfortable and there is an opportunity to view all the data on the order, it is possible through the scanner, through the phone itself to find the order that needs to be given, in which car. That is, these are the advantages that affect the number of orders per day, and this is the main thing, of course. Because the more completed orders, the more money the driver will receive.
And another interesting feature in the roadmap is that in the future our application will be like a neural network, that is, it will be smart. What does this mean in practice? Let's imagine that a driver arrives at a new address in an unfamiliar area, and our application tells him how best to drive to the house where the barrier is located, what kind of access system is there, what code is on the door, and so on. That is, in the future we plan to provide such tips with specific information that is not freely available. We plan to connect a data scientist to collect data from drivers and show them to other drivers, thus simplifying their lives during the working day.
To what extent OnGo Fleet is a full-fledged DMS (Delivery Management System) or TMS (transport management system), that is, to what extent can we compare one of our products with what whole large companies are doing. The question is about ambitions, how fully we develop it all.
The only thing that we have not developed now, but will be developed in the future, is interactivity, statistics, maps and so on, which has already been discussed. We have been working and are working to make our application as convenient and useful as possible: to prompt drivers how to enter a particular building, to correct their actions. We are confident that we can compete with large companies that have been working on similar software for several years.