Whitepaper for your new fleet management software

How do I find the right software for my fleet management - and how can I implement it without any stumbling blocks? That's what we're talking about today with Oliver Riedmüller, our experienced Key Account Manager. He knows the typical challenges in the procurement process - and what really matters.

Oliver Riedmüller: Every fleet has individual requirements. Companies should carry out a needs analysis and clarify with the relevant departments which functions are actually required. An all-in-one platform such as the AZOWO Mobility Cloud comes very close to providing the right solution, as it is smart, flexible and sustainable.

A typical example: a group with pool vehicles, e-vehicles and classic company cars wants a platform that integrates modern corporate mobility from scheduling to fuel card management. At the same time, the solution should also cover traditional processes such as driver's license checks, automated reporting and telematics. In practice, this means that a single software should be able to meet all of these requirements in full. It makes sense to check the integration with existing systems based on the critical functions.

Oliver Riedmüller: The needs analysis is the foundation of every successful digitalization project in the fleet sector. If you skip this step, you risk implementing a solution that fails to address the actual challenges. Unclear requirements lead to misunderstandings and unsuitable offers. Providers interpret gaps differently, which can later lead to expensive renegotiations or unusable systems - with corresponding delays throughout the entire project.

A typical example: A tender simply states "We need a vehicle management system". But what does that actually mean? Is it a simple booking platform? Or a comprehensive system with automated driver's licence checks, damage reports, billing and pool vehicle optimization? Without a precise definition, there is a risk that the solution offered will not meet the actual needs.

This is why it is essential that companies carry out an internal needs analysis in advance and involve all relevant departments at an early stage - from IT to HR and purchasing through to sustainability management. This is the only way to gain a holistic understanding of the requirements. The needs analysis creates clarity about the status quo, uncovers inefficiencies and defines measurable goals. This is the basis for a targeted software selection and for a project that ultimately creates real added value.

A detailed catalog of requirements helps to avoid misunderstandings later on and ensure that all perspectives - from fleet management to IT and compliance - are taken into account. A concrete example: a car sharing provider planned to integrate processes such as digital driver's license control, billing and key management in addition to vehicle scheduling. It was only through a structured catalog of requirements that it became clear that the solution needed open interfaces to billing systems such as SAP, a mobile app for drivers and scalable IoT integration for digital keys.

Such requirements can be meaningfully structured and prioritized in a catalog of requirements - for example according to functional, technical, legal and business criteria. This not only facilitates communication with providers, but also enables an objective and comprehensible comparison of different solutions. Those who take the time to conduct a thorough needs analysis create the best conditions for a successful digitalization project - efficient, needs-based and future-proof.

They are crucial. Providers can only customize and offer their solution if they know exactly how the company actually wants to use the software. I recently had a client who simply said, "We need digital fleet management." After asking around, it turned out that they just wanted a specific solution that would allow employees to book pool vehicles via an app that automatically optimizes availability and automatically assigns vehicles based on usage. These are different requirements. With clearly defined use cases, providers can show specifically how their solution solves the problem.

Oliver Riedmüller: A cheap offer is not always the best choice. Companies should not only consider the purchase price, but also long-term costs such as maintenance, support and scalability. For example, one company opted for the cheapest software solution because it was 20 percent cheaper than the competition. Only after six months did it turn out that the solution had no interface to the existing ERP system. The subsequent integration was so expensive that the company paid more than for the more expensive but fully compatible solution. Using an evaluation matrix that takes into account scalability, support quality and security standards as well as price, the companies find clarity.

Oliver Riedmüller: A modern fleet management solution is rarely a stand-alone solution. It should be seamlessly networked with existing IT systems such as ERP, HR or telematics solutions as well as charging infrastructure management in order to develop its full potential.

An illustrative example from practice: a company used SAP for its financial accounting. However, after introducing new fleet management software, it turned out that there was no direct interface to SAP accounting. Postings had to be transferred manually - an unnecessary additional expense that could have been avoided.

The case clearly shows how important it is to define interface requirements at an early stage - ideally as part of the tendering process. If the IT department had been involved at the outset and the technical requirements had been jointly agreed, a tailor-made solution could have been selected.

This is why we recommend actively involving your IT experts from the outset and formulating specific requirements for integrations, data security and the system landscape. This will not only ensure efficiency in ongoing operations, but also create a stable technical basis for a future-proof fleet solution.

Oliver Riedmüller: Very much so, yes! If providers don't confirm the requirements in advance, they may offer unsuitable solutions or "hidden" costs may emerge later. Companies can talk to providers in advance to sound out the market, get to know the technologies and get a realistic idea of prices, functions and implementation costs.

All providers should have the same opportunity to receive information in order to avoid preferential treatment later on. One formalized way is an RFI (Request for Information). This is a non-binding request in which providers supply information on technical options and market trends. A company is planning a cloud-based fleet management solution and asks for information in advance via an RFI: What cloud technologies are providers using?  What security standards are standard? What does a typical implementation time look like? This provides the company with valuable market data without having to commit to one provider.

In some cases, it can be useful to hold workshops with several potential providers before the tender. This allows companies to describe their challenges and compare different solutions. A documented, transparent process with clear criteria should be followed here so that no providers appear to be favored later on. Larger public tenders can be preceded by a pre-qualification process. Companies or authorities define minimum requirements and interested providers can qualify.

This means that providers can be involved before an official tender as long as this is fair, transparent and well documented. Strategic preliminary discussions, RFIs or workshops help to create a practical tender and avoid problems later on due to unrealistic requirements. A lengthy adaptation process with additional costs can thus be avoided.

Oliver Riedmüller: Often, not every aspect of a project can be clarified down to the last detail in the run-up to the procurement process or tender. This is precisely where queries/bidder questions come into play - they are far more than a formality. Used correctly, they help companies to identify ambiguities, sharpen requirements and avoid undesirable developments later on.

A good example: In a tender, a "secure API connection to existing systems" is required. A provider asks: "Are there any specific security standards or certifications that need to be met?" This query shows that the original requirement may have been formulated too vaguely. This gives the company the opportunity to clarify its requirements and ensure that only bids with the right technical depth are received.

Bidder questions are also a valuable quality check. If several providers ask the same question, this indicates a gap in the requirements catalog or unrealistic expectations - a clear indication to make adjustments at an early stage.

Another example: a provider asks whether the system can also be operated as a pure on-premise solution. If the company actually prefers a cloud-based solution with high security requirements, the answer may be: "Our preferred architecture is a cloud solution in accordance with ISO 27001. An on-premise version is not planned." Here, too, the exchange creates clarity - on both sides.

The best results are achieved through dialog. Q&A sessions or structured workshops with potential providers promote a shared understanding of objectives, priorities and technical framework conditions. In procurement processes, fleet operators are often initially presented with very narrowly defined catalogs of criteria. It is not until the workshop that it becomes clear that many of the desired functions were already included in the solution as standard, while others could be easily added thanks to open interfaces. Without this exchange, a suitable provider might not have scored at all - or would have been eliminated from the process at an early stage.

Transparent communication during the tendering process creates trust, reduces misunderstandings and saves a lot of time and money during implementation. Companies that actively respond to questions and promote exchange ultimately benefit from more accurate offers and more sustainable decisions. An example: In a procurement process, a rather narrowly formulated list of criteria was initially presented. It was not until the joint workshop that it became clear that many of the desired functions were already available out-of-the-box - while others could simply be added through open interfaces. Without this dialog, a provider with a precisely tailored solution might not even have been shortlisted.

Transparent communication creates trust - and saves a lot of time and money later on during implementation.

Oliver Riedmüller: Standard presentations rarely deliver the added value that companies really need. If providers do not tailor their solutions to the specific challenges of a company, their benefits remain abstract - and therefore irrelevant. A targeted presentation based on a clearly defined set of expectations is crucial. For example, if you want to improve the utilization of employee vehicles, you don't need generic vehicle management software, but a solution that addresses precisely this need - with functions such as intelligent booking algorithms, automatic vehicle allocation and real-time availability.

The product presentation is the moment when it becomes clear whether a solution really works in everyday life. Companies benefit when they introduce practical use cases - for example: "How does an employee spontaneously book a vehicle?" or "How does the key handover work at night?" Such scenarios make it tangible how intuitive, flexible and efficient the software actually is - and whether it noticeably improves processes.

A concrete example: a customer from the energy sector opted for our solution after a live demo because the digital driver's license check was integrated directly into the booking process - simple, mobile and without additional effort. For the customer, this means less administrative work, greater legal certainty and a significantly better user experience for employees. It was precisely this tangible added value that was decisive in comparison to other providers.

Oliver Riedmüller: A successful tendering project always starts with a solid internal requirements analysis. Companies should involve all relevant departments and specialist areas in the planning at an early stage. This helps to clarify internal processes, interface requirements and future scaling needs at an early stage. Only if everyone involved pulls together can realistic requirements be defined that will not lead to unexpected problems during subsequent implementation.

The next essential step is the precise formulation of requirements. This includes a detailed description of the use cases so that providers understand exactly how the solution will be used in day-to-day business. In particular, technical requirements such as interfaces, data security and automation options must be clearly specified. If the tender is too general, this will lead to non-comparable offers or missing functions in the subsequent solution.

Another decisive success criterion is a transparent evaluation of the offers. Many companies focus too much on the price and overlook long-term factors such as scalability, support quality and integration capability. A low-cost offer can later turn out to be cost-intensive if important functions are missing or running costs are higher than expected. An evaluation matrix that takes into account both economic and functional criteria helps to make a sustainable and economically sensible decision.

In order for providers to really show how their solution meets the company's individual needs, customer-focused presentations are crucial. Standardized product demos are not very helpful - instead, providers should demonstrate their solution based on the company's specific challenges. This can be achieved by specifying a clearly defined use case in the tender. This not only checks the practicality of the solution, but also shows which provider really understands what is important.

Finally, the company should deal with realistic SLAs (service level agreements) and the operating concept at an early stage. Involve IT and security at an early stage to define security standards, support times and hosting models. Companies often demand 24/7 support or an on-premise solution, even though these incur high costs in the long term. A realistic consideration of the actual operating requirements ensures an economically viable and technically feasible solution.

If companies adhere to these steps - internal needs analysis, precise requirements, transparent evaluation, customer-related presentations and realistic SLAs - the tender will not only be successful, but will also lead to a long-term, economically sustainable project.

Your guide to successfully selecting and introducing a fleet solution can be downloaded free of charge below.