01 Overview

This is an internal application used for the troubleshooting and configuration of payroll for clients. Currently there is no specific tool that monitors the status and all other client specific payroll data. Operations Dashboard allows for clients to be seamlessly implemented and re-configured in the case that information changes down the road. It allows for their ADP representative to track and resolve issues to prevent late or incorrect payments. The tool is targeted at making complex payroll data more understandable to less technical employees which allows for issues to be caught and fixed more quickly.

This was the first product in the department to be deployed and used by real users in real time.

02 Goals

Create an Automated Process
By creating a more automated process we reduce the time it takes to implement a new client and we allow for users to be more proactive in order to prevent serious errors in a clients payroll.

Reduce Human Error
Humans are prone to make mistakes. By creating an application that constantly monitors processes and surfaces errors immediately we make it faster to catch and resolve those issues.

Troubleshoot Faster
The system surfaces errors and discrepancies to the users. We also bring forward more important information that helps users know who to contact and how to resolve those errors.

Consolidate Features
Before this tool none of this information existed on the same platform simultaneously. By bringing it together we greatly reduce the time it takes for users to find the information they need.

03 Payroll Status

The payroll status page allows for one user to track payroll submissions for multiple clients at one time, sort errors based off of the date run, and dive deeper into errors so that they can quickly troubleshoot and resolve issues and make sure payroll is submitted on time.

04 Error Types

Retry Ability
All notifications that are thrown within our department can trigger the process to restart where the error was thrown. In some cases this is the only action required. Future iterations from the development team removed the need for a refresh and kicked this process off automatically.

Multiple File Failures
Because there are multiple files that have to be processed and transmitted throughout the process it is possible that issues could arise with both. We surface these on separate cards that are resolved individually.

Transmission Failures
Files have to be sent to other departments for processing, so it is possible that the “gates” from our department could be closed. It’s necessary for users to be able to toggle this function for troubleshooting.

Dismissible Errors
In the case that errors are thrown in other departments we still surface those issues so that the user is aware of them. However, no action can be taken by our users so we allow for these errors to be dismissed and hidden.

05 User Testing

We had the privilege of working with real-time users on our application. After deploying the application our product manager set up biweekly meetings to sit down and discuss current features and future requests with our users. Our meetings brought our application from just a tool used to monitor status to one that would assist them in all of their day to day activities.

A comparator tool was one of the biggest asks. The new application required a lot of comparisons with the old system in order to ensure that everything was running smoothly and correctly. There are several different files throughout the implementation and payroll process that are created and can be compared with old systems. We created a way for clients to be able to see and upload their data to our system. We would then automatically process the data and display it for users to compare to the old system. This was only slice one of the comparator. Later iterations will completely automate this process and import both data sets into the system in order to flag discrepancies.

06 The Future

This application was in the process of a re-design. I helped to map current features to those in the future and work through the restructuring of the entire process with the product team. Over time it had become cluttered and unorganized so we wanted to refocus the application. The end goal was to make the entire application client specific, where users could toggle between different clients at a high level but still navigate through pages and information for the same client. On the current design users have to re-select the client they are looking at with every new page.

Below is the proposed restructuring of the current dashboard pages based off of their categories.