HTML Reporting Tool

Introduction

This project can be found at this link.

Software tools often make the world go round. They connect us, deliver our food, and even guide us to our destinations, but they typically have entire departments working in the background to make the magic appear magical. This is a story about how an employee seeking an audience with engineering earned that chance. 

Backstory

In 2017, I started working as a Customer Service Representative for a software company called OpenTable. This role was, in a way, not what I wanted ultimately, but I had little corporate experience and felt it would be easier to work my way up then just happen across the job I wanted. So, as a CSR, I was looking for ways to be more valuable than what the minimum effort required (answering phone calls from clients and customers alike) would produce, such as creating tools that provide reporting access to every employee, not just the engineers. 

Code projects have always been of interest to me, so when a colleague presented a tool that was just sending CURL calls to a server, which in turn sent back reporting data to the browser, I knew that I could conceptualize, design, build, and deploy an interface to aid in the use of this backend tool.

Audience

For many large corporations, the happiness of the customer service department is not a primary concern, so often needs to go overlooked when there isn’t the budget or time for a fix. These results in employees that don’t have answers the clients need, and no way of finding those answers other than to say “I’ll file a ticket for this”. This usually results in a frustrated client or customer, because the potentially new support agent sincerely doesn’t have an answer or a way to find one. But in this case, I took something that was being used by the Tier 3 Support Engineers, and made it accessible for every Tier 1 Support Agent on the floor. To this day, the tool, is still being used by the higher tier support agents.

Although the company sets up multiple monitors and capable workstations for the employees, the software world is ever-changing and frequent updates result in calls to customer service with questions and demands. This designed tool empowers those who had previously answered “I don’t know”, or “I’ll have to ask my superior” to find those answers themselves through use of an easily accessible web tool. 

Problem

There was no official request for this software. The engineering team had provided a bare-bones ability to access server logs, but it was not a usable interface. Rather, I saw the need to design the frontend for an existing backend service, and acted upon it with the tools at hand. Though, if I’m being truthful, the drive to prove myself, as more than my current station, pushed me to look for opportunities. Although I was only a Customer Service Representative, I had knowledge of websites and how to code already, so I wanted to push myself to create something that the Engineering department hadn’t deemed a good use of their (expensive) time. 

Process

Starting with just an idea of what could be, I had a CURL script and time on my hand. I needed to design something that was easily usable while also not restricting the power of the reporting functionality. This required hours of crafting HTML and CSS into a usable feature. I first needed to create the basic HTML form, then study the API to see which different parameters it would receive. After that, I started to craft an actual interface, pixel by pixel.   

Initially, it was a tool that only I knew how to use. Then I slowly distributed it to some senior employees in the call center as a single HTML text file. I would teach them how to use it as installing. All this while I was coding this file between phone calls and at home during my free time.

This worked, but as I developed newer versions, I needed an easier way to update the software without going to every person’s machine and updating manually. At first, I deployed an Apache server with the file, located at an IP address on the network, but this was not elegant. 

So, I met with the Engineering department, and they were able to set me up with a domain and a server to host my software on. They also were able to guide me toward the style guide in their documents, so that my tool could match the company environment. Now, the employees are able to access a home-built tool through a simple URL, just like any other website. 

Media 

In chronological order, starting with the early versions.

Below, a comparison between the official OpenTable enterprise software, and the backend reporting tool built.

This code file contains over 1800 lines, so this is purely an introduction.

Lessons Learned

Initial feedback on the tool was very positive, from the customer service agents using it to the engineering team reviewing it. There were comments about how I had initially not followed the style guide for the company, though as a bottom level employee, I hadn’t been exposed to such knowledge. I learned much through this process, such as frontend design and web server hosting. Over several months, this project progressed from a hacked idea to a full-fledged product that an enterprise corporation takes advantage of daily. Using technologies such as Apache, HTML, JavaScript, etc. I learned a great deal more about building applications, and deploying them to the users efficiently. In the end, the final product was a usable application, assisting hundreds of employees.