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 Problem (surface level)
The company's engineering resources were being wasted dealing with re-occurring support tickets caused by infrastructural issues with the fuel transaction import.

The engineers could not focus on the main product.

The Problem (under the hood)
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 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.

Moving forward there were two options: working with the software engineering (SWE) team to implement a solution in the backend or designing  a solution myself in the middleware.

Years of working for Collective Data gave me extensive product middleware knowledge. This understanding included both functionality and database perspectives. I worked with app devs and software engineers daily. Their knowledge passed on to me.

Leveraging this knowledge, I first started to map out the information architecture and user-flows. Both of which were enhanced by the information gained during the research interviews.
‍
How did research impact the designs?
An example of the info gained during research was finding out that customers could be integrated with multiple third party vendors. Customers informed me they wanted odometers to come from source A but fuel transactions to come from source B.

So I added an "integration" field. The values being the third party company's name.

With the integration field the system could differentiate imported transactions by source and what data was brought in.

Roughly 35% of our customers have atleast one fuel integration, with half of those customers using the advanced fuel integration (as of July 2022). The improved fuel integration module now groups records by the vendor, month, and fuel type. End users are able to resolve any errors with the imported transactions directly within the system.

What went well?
The time app devs were spending to fix data after an issue occured with the third party was drastically reduced. The easy to understand workflow/UI allowed support agents to field a lot of the questions.

The internal training seminar I lead to train the client trainers how it works went really well too.

What could have gone better?
‍The reason why this was an issue in the first place was a sales rep who decided to design and override the design/dev team.

Their version was first sold in 2011.
My version released in 2019 after I started at the company in 2017.

That's a solid 8 years of our system not better handling data import issues and pissing off customers. That should have never happened.

In addition, if the SWE team was more available some of this functionality could have been implemented in the backend for better performance with large data sets.