Queen of Sheba
OVERVIEW
The Queen of Sheba is a debt collection application designed for a mid-sized telecommunication company and is used in conjunction with Solomon accounting software.
Side note: We gave this project the working title, Queen of Sheba. The name is borrowed from a historical ruler from southwestern Arabia who interfaced with King Solomon (Solomon being the name of our accounting software). It is a tad tongue-in-cheek, but it is said that she tested his wisdom with riddles and scenarios. Rumor also says that they had a son together who begat the Ethiopean dynasty.
ROLE
Lead UX/UI Designer
CONTENT
Research, UX Design, Prototyping & Testing, Information Architecture
June 2014 - August 2014
BACKGROUND
The interface needs to be simple but efficient, to allow a collection agent to work quickly with what could be an irate or upset customer. Ideally the module will interface with other departments to red flag customers for future component sales and credit limits.
THE PROBLEM
The biggest issue was that the collection software was not displaying the most current customer financial changes, such as credit holds, and in process transactions, causing the collection agents and sales associates to make costly errors when working with customers and their accounts. The information needed to be updated immediately and be visible to both accounts receivable and the sales team. The current software had limitations on formatting and was unable to do this effectively. Ideally the module would interface with other departments as well, such as procurement and shipping, to red flag customers for future component sales, limit procurement of unnecessary parts, and halt the shipment of outgoing parts.
PROBLEM STATEMENT
“How can we design a software solution that displays up-to-date and real-time customer financial status and information, enabling accurate decision-making and seamless coordination within collections and across all departments.”
RESEARCH
The main goal of this project was to create a collections department specific interface that organized the customers’ data and displayed customer status in a way that reflected the processes and needs of the collection team so that they could do their job more efficiently and effectively.
To begin we familiarized ourselves with the accounting software and the processes and work arounds the collections team were using to get the job done. We also looked into market options but though we found several, the majority of these apps were very costly and complex and would have been very difficult to integrate effectively with the company’s custom-built ERP system.
USER INTERVIEWS
To further my understanding of the problem, I interviewed the head of collections and her staff and sat in on some of their processes. I also spoke with Sales, Procurement, and Shipping to get a more cohesive idea of what information was needed across departments.
With the information gathered from the interviews I was able to piece together a simplified map of key processes, compile a list of pain points, and develop three collection agent personas:​
Additional interview takeaways:​
-
Specific individuals I interviewed used non-standard words to indicate certain standard financial terms or processes. I had to clarify what the words meant to them and then put together a individualized dictionary of the non-standard terms and their meanings so that I could communicate effectively with them about the project. ​
-
There was positive feedback about including "non-patronizing" direction within software to help less experienced collectors be more productive. ​​​​
USER PERSONAS
PROCESS MAPS
Our next step was to put together a series of process maps to better understand the collection process. Here are three of the main situations we identified.
Situation #1: Customer’s Account is overdue
-
Collections Dept. receives notification that a customer’s account is overdue.
-
Customer is assigned a Collections Agent.
-
Late fees are applied to customer’s account per contract terms.
-
The customer’s account is placed on hold, no payable work can be done, and no equipment can be purchased without managerial override. Customer is flagged across departments including sales, purchasing, and shipping.
-
-
Agent attempts to contact customer, phone OR email. Each point of contact attempt, response are detailed and recorded in customer’s account.
-
IF contact is made, the customer can either make a payment or payment arrangements to pay off balance and keep account active.
-
IF contact is NOT made within the time allowed, per contract, an overdue notice is generated and mailed to the customer.
-
IF contact fails 3 attempts and the account is not reconciled within allotted grace period, the account goes into default mode and the customer is put on a semi-permanent hold. NO NEW ACTIVITY CAN BE CREATED ON THE CUSTOMER’S ACCOUNT UNTIL DEBT IS PAYED
-
-
IF customer pays off debt, the account can be activated again at management discretion, but the customer is flagged as high risk and a prepayment for services and/or deposit is required, dependent on customer risk assessment.
Situation #2: Customer Bankruptcy
1. Collections are notified by the customer or an outside source.
2. A temporary flag is placed on the customer and account placed on hold.
3. The agent will attempt to collect the debt until proof of bankruptcy is given (see Situation #1).
4. Once Proof of Bankruptcy is given, the customer’s account is placed on permanent credit hold and all outstanding debt is marked as bad debt.
5. Customer Care is notified to schedule return of loaned equipment.
Situation #3: Billing Error
1. Customer notifies collections that their account is overdue because of an internal accounting error.
2. Collections works with Billing to track down the error and correct it.
3. The account is adjusted, and the hold is removed.
APPLICATION REQUIREMENTS
Finally, we created and refined a list of specific applications requirements [I will not list it in full here as some of it contains proprietary information]. Here is a general list of must haves:
-
Access customer account information by Master Customer and/or by Site.
-
Search and view customer docs by customer, site, payments, grouped invoices, aging and documents with zero balance.
-
Overview of the customer’s account standing, including Open Balance, Overdue Balance, Billing Type, Billing Address, Mstr Credit Limit, and Credit Hold Status (editable).
-
Create and edit notes for customers to track actions taken by customers and by agent. Ideally searchable/filterable at multiple levels.
-
Create/edit scheduled action items by master customer.
-
Provide accurate and up-to-date data!
TESTING & REFINING
As the application evolved from wireframes to full color mockups, we continually user-tested them with the collections department. Being that the Queen of Sheba was such an extremely robust and data heavy application, it was essential to keep the stakeholders in the loop to catch any errors and identify any needed changes in real-time.
Using feedback from our interactions with the stakeholders, we added a robust notes tool that enabled the collection agents to assign notes (internal communications) and action items at the customer level, the site level, on the individual invoice, and within a grouped invoice from a central location. These notes and action items could then be filtered by the agent to the level needed. Lack of communication within the system was one of the major pain points identified by the collections dept. This addition greatly improved communication within the department.
As we progressed, we added in methods to give visibility to the other departments. We tested indicators and flags added to the main customer page, and to the procurement and shipping department interfaces so that sales, shipping and procurement would be kept in the loop. ​We also spent time visually refining the layout and creating a set of collection specific icons.
Finally, we ran exhaustive tests in pre-production with the stakeholders and the accounting department to ensure all the data was compiling and displaying correctly. With some small adjustments to the code and buy-off from both accounting and collections we deployed to production.
SOLUTION | Web Application
The final product gave the collection department a curated view into the customer's account and account status, while also equipping them with the tools they needed to communicate effectively within and between departments.
SUMMARY
The project was overall a success and well received by the users. There were a few humorous data inconsistencies when we first deployed to our test environment. The way our code pulled the data made some of our numbers much more technically up to date than our accounting software. Our program counted all payments whether they were batched or not. This gave the agent a better real-time view of the customer’s account in a collections format BUT unfortunately, we had to adjust this to match the numbers in the accounting software so as not to confuse the accounting staff too much.
A year after the project was complete, the company attempted to switch to Salesforce, but to our credit, collections refused to switch and continued using our software for several years because it worked better for them.
TAKEAWAYS
Through this process, I learned many things, most notably that when communicating ideas, being able to adjust your terminology to fit someone's else's is extremely beneficial. The Collections manager I worked with had a slew of terms that she used that did not match the known definition. I had to create a list of her personalized terms with definitions so that I could effectively communicate my ideas with her using her own terminology. Generally, she was considered a difficult person to work with, but we got along really well after I figured out how to communicate with her.
