how we work



While we are quick to cite the technologies we use, it's often the projects we've completed that make the most impact with potential clients. We've included a few here to demonstrate some of our abilities. If you have a project you would like us to take a look at, please drop us a note.

Proprietary Card System

Synopsis: A large jobber was acquiring a large number of sites and a proprietary card platform that was incompatible with its own systems

Goal: Develop a system for maintaining cards and authorization updates at a customer service, as well as customer level.

Any acquisition is stressful - there never seems to be enough time. Oly Services was tasked with understanding an under-documented proprietary card network and working with the processor to develop new processes to duplicate (and improve) the current functionality. In 45 days.

We worked with the processor to define a specification and a new process for sending updates for accounts, cards, and vehicles. We had a database dump and processing specification draft that was 20 years old to piece together how everything worked. By the end of the project, the processor had updated the specification five times to adjust for newly discovered functionality.

From a functionality standpoint, we had to provide for new account creation including the numeration of the account and assignment of limits. We would develop dynamic card creation forms for their customer service and customers, auto-numbering or custom card numbers with validation. The vehicles would be either floating or tied to specific cards. The system would need to update at an interval as close to real-time as possible.

Fortunately, we already knew the client's current systems and workflows. We were able to jump right into development on their Intranet to integrate features for the new card. The customer portal was new, but mimicked the current look/feel to cause the least amount of problems for the customers.

We built a SQL job that polled the account, card, and vehicles database every five minutes for any new or updated records. We used a simple system of 'status' definitions that indicated whether a record was new or had been changed. The SQL process would then create a text file with the update information and send it up to the processor. Each update would record changes for a full history on card and vehicle updates. We also developed a card printing system that generated a print file for the cards and an interface for their operations team to administer.

Along the way, we had plenty of problems to deal with, mainly because we lacked a subject matter expert on the network or processor. Nevertheless, we launched on the agreed upon due date and the system is now operating efficiently and without our intervention.

Report Builder

Synopsis:A client was spending a lot of time creating custom reports for customers.

Goal: Develop an intuitive custom report builder system within their customer portal.

Reporting is very important across all departments, but carries an even more important role in the customer relationship. In a business that competes for pennies per gallon, more often than not you hold on to customers through exemplary customer service. While cost is important to the customers, more often than not the information you can provide on those gallons is just as important.

Not only is reporting providing transaction data, it aids customers in managing their fleets and related expenses. The more detail you can provide the more value you bring to your customer. The potential downside is that while you can satisfy most customers with well thought out reports, you won't please everyone and you can start heading down the rabbit hole quickly churning out variations of popular reports.

We had developed over a dozen reports for a client's portal that included raw and priced transaction and invoice reports, IFTA, detailed and summary tax reports, as well as exports conforming to municipality specifications. Despite that, their customer service was spending a lot of time taking existing reports and tweaking it to suit customer requests: delete this column, move this column here, add a total. On one hand this was superb service, but inefficient and thus, costly.

We took the basis for the majority of these custom requests and determined that raw and priced transactions were primarily the basis for the reports. If we could provide a report "builder" for the customer that enabled them to create the report exactly the way they wanted and generated at the frequency they needed, we could alleviate a lot of the customers service rep's work.

We had some challenges. The transaction reports pull data from the transaction records, but also from accounts, cards, sites, and other database tables. Therefore, we had to design a system that pulled all of the relevant data in without complicating the interface. The delivery system was as important as the report builder itself and we allowed for a variety of delivery options. Reports could be generated on demand or daily, weekly, and monthly, sent to up to five email addresses. Once a report was built and saved, it was part of the customers report library.

Once the report builder was created, we trained customer service who in turn trained customers. However, we wanted it to be intuitive enough that customers with no training could figure it out. We found that not only did customers take advantage of the system but customer service was using it to build reports for customers. So it was beneficial for everyone.