Streamlining Fuel Management for Large Fleets

• Improved time to resolve data issues by 90% (weeks to hours)
• Immediate notification of data issues via email
• Data issues (when they occur), are detected immediately
• Users avoid costly data cleanup

I proposed and designed a new framework to address infrastructural issues that were repeatedly wasting company engineering resources to resolve.

Collective Data? Construction, utilities, & law enforcement agencies utilize Collective Data's enterprise asset management software, Collective Fleet, to track, among other things, fuel usage for their fleet of vehicles. Collective Fleet can also integrate with third party fuel vendor apps to synchronize data.

The company's engineering resources were being wasted dealing with re-occurring support tickets caused by infrastructural issues with the fuel transaction import. Engineers could not focus on the main product.

The middleware handling the data was not robust enough to handle certain scenarios. Simple scenarios such as 'Does this vehicle exist in the system?' did not gracefully fail or notify users. A data issue could persist for months before anyone noticed. Data clean-up is expensive for users.

To expand my understanding of the problem, I met with internal support agents and account managers. I also interviewed representatives from the third party companies we were importing from to establish a knowledge base of the data they gathered and what was technically possible. Our system could be adjusted to detect and notify users of when problems happen and how to resolve them.

My new design would first detect missing or bad data based on preset metrics (which could be updated later). As seen in the service flow below, if bad data is detected, the records are flagged and the end-user is notified allowing them to take action.

Years of working for Collective Data gave me extensive product middleware knowledge. This included both functionality and database perspectives. I worked daily with app devs and software engineers, learning from them.

Leveraging this, I mapped out the information architecture and user‑flows. Research revealed that customers could be integrated with multiple vendors. Some preferred odometers from source A and fuel transactions from source B.

To address this, I added an 'integration' field to differentiate imported transactions by source and what data was brought in.

The following diagrams illustrate the original 2021 system architecture and data flow that was designed to handle fuel transaction imports and error detection.

Object hierarchy and field relationships (Original 2021 design)

Integration event flow and approval process (Original 2021 design)

Throughout the design process, I collaborated closely with the application development team through whiteboarding sessions to map out business logic and system requirements.

Whiteboarding with the application development team - Business logic planning

Whiteboarding with the application development team - Early conceptual planning and UI exploration

Roughly 35% of our customers have at least one fuel integration, with half using the advanced version (as of July 2022). The improved module now groups records by vendor, month, and fuel type. Errors can be resolved directly within the system.

• Improved time to resolve data issues by 90% (weeks to hours)
• Immediate notification of data issues via email
• Data issues are detected immediately when they occur
• Users avoid costly data cleanup

The time app devs spent fixing data after third-party errors dropped significantly. Support agents could handle most questions thanks to a clearer UI.

The internal seminar I led for the client trainers also went well.

But—this shouldn't have taken 8 years. A sales rep originally designed the feature in 2011, bypassing design/dev. I redesigned it after joining in 2017, shipping in 2019.

If the SWE team had been more available, some functionality could've gone into the backend for better performance at scale.