
Consumer Service System
OVERVIEW
As a consumer reporting agency, this company handled the consumer data of millions of people. Consumers have a legal right to dispute information on their reports, and their agents need to fulfil these requests in a timely manner. I was called upon to create a new system that gathered their disparate processes into one place.
RESEARCH & IDEATION
I began with understanding their process. Through meetings with their team lead, we were able to map out their workflow. With this, we identified the pain points and came to an understanding of the project’s requirements.


The processors required an application that would allow them to track and work on different types of consumer requests. They needed to be able to create a new request, known as an “event” while on the phone with the consumer and actively taking notes. They needed a way to search through events in case a consumer called and asked about their case, and they needed a way to stay on top of a workload that involved multiple consumers and tasks at a time.
With all of this in mind, I began with building a basic wireframe in Axure. This wireframe was brought to the processors for user testing, and the insights from the testing results informed the changes and features that needed to be made as we moved into the prototyping stage, which was also done in Axure.
RESULT
The processors manage their events with the queue on the main page. This page features the personal queue of their assigned work, as well as a master queue that allows them to access the events of other team members as needed. From this page, they can also create new events.

To create an event, the processor enters the consumer’s information and selects whichever event types best suit the consumer’s request. Some consumer requests call for multiple events, so the processor can create more than one, and then select which event they would like to tackle first. The rest will be waiting for them in the queue.

On the event page, they can start working on the tasks necessary to complete the consumer’s request. Combing through the consumer information on file, they can use this application to create a to-do list of “tasks” for things like reaching out to credit bureaus, creditors, and county clerks (for disputing public records). While most of these tasks can be handled through online systems, some county clerk offices require catching someone on the phone, which isn’t always achieved on the first try. To combat this, the program allows processors to set up a reminder to try again later.
As an event’s tasks are completed, the processor can close them off one by one, and use the system to automatically generate letters that are sent to the consumer, informing them of the results of their request.

CONCLUSION
When the prototype design had been completed, it was passed on to the development team, but I remained available to answer any developers’ questions about the design or the users’ needs.
After the application reached production, I conducted further interviews with the users to follow up and ensure it was working well.