Written by Andy Morrise
Updated on March 21st, 2023
Table of Contents
Audience: Loan Servicer or Collector, Developers, Loan Servicing/Collections Managers, Data
Introduction
In LMS, borrowers and loans are not synonyms. A borrower can have multiple loans, and a loan can have multiple co-borrowers. Most of our labeling options are applied at the loan level—checklists, portfolios, and loan statuses all apply to individual loans, and not the borrowers themselves. If each loan only has one borrower, and each borrower only has one loan, then you don't really need to track customers independently from their accounts. But if you have secondary borrowers attached to loans, or a single customer with several loans, you may need a labeling tool that's specific to customers.
With customer statuses, you can create a custom list of labels that apply to the borrowers themselves.
Clojure Use Case
Use Case: Customer Status/Clojure
The Problem:
A lender extends several loans to a single borrower, but then that borrower goes active-duty in the armed forces, qualifying for an SCRA adjustment to their interest rate across all of their loans. Instead of just editing one loan, the lender needs to edit several and keep track of which loans still need to be changed. And they'll have a similar problem anytime a borrower has an issue that affects multiple loans, like bankruptcy or retaining an attorney.
LoanPro's Solution:
When borrowers have a problem that affects multiple loans, its best to track that problem on borrower themselves. You could set up customer status as a trigger for automated processes on each of their loans. You could use Rules Applied to create a rule where changing the customer status to “SCRA” would then change the loan status, portfolios, and other loan settings. You could also use customer status as a variable in other areas, like computation fields, trigger-based notifications, or custom forms. Together, these tools let you kick off automated processes on all the customer's loans at once, saving you time and helping you stay compliant.
Webhook Use Case
Use Case: Customer Status/Webhooks
The Problem:
Rules Applied is a customizable automation system in LMS that allows you to specify criteria, and when those criteria are met, the system will automatically update the loan with actions you've set up. The list of possible actions is pretty long, but it does have limits. It takes our developers time and effort to add a new action, and they simply can't foresee every possible action that lenders will want to automate. That means that some parts of the software—like customer information—can't be updated with our built-in automation tools.
LoanPro's Solution:
That's one reason why LoanPro built Premium Webhooks, which originated as a notification system to communicate between LMS and other software. Basically, you set up an automatic notification, and when it goes off LMS sends an update to a website that you specify. That can website can be LMS, triggering changes on loans and customers in the software.
Setting up webhooks requires some knowledge and technical expertise, so we recommend you work with our support team.
How Customer Statuses Work
Customer statuses are created at the tenant-level and then applied to individual customers. You'll have a single list of labels that can be placed on individual borrowers. Just like how each loan can only have one loan status, each customer can only have one customer status at a given time.
To use them, you'll start with creating your statuses in the Settings tab. Then, you'll navigate to an individual customer's page and update them with the appropriate status.
Common Uses and Questions
Here's what each person at your company needs to know about customer statuses:
Loan Servicers and Collectors
To edit a customer's status, you'll need to navigate to their page in LMS. You can either do this through the Customer Manager or through the customer tab within a loan, where you'll have the option to change the status of any customer linked to that account.
Developers
To update a customer status with the API, you'll use the same PUT request as you would to edit other core customer information. You can find the request on our ReadMe site, complete with customizable endpoint, headers, and JSON payload for testing.
If you're asked to write any Clojure rules that use customer statuses, the variable can be written to refer to either a primary or secondary variable. For details, see our article Context Engine Glossary – Customer.
Loan Servicing/Collections Managers
Statuses can be useful in and of themselves as a quick label telling agents about a borrower, but you'll get a lot more out of them if you combine them with other LoanPro tools.
- Clojure Rules in Rules Applied, computation fields, or trigger-based notifications can use customer status as a variable.
- If you're updating customer statuses as well as loan labels (like loan statuses, portfolios, and checklists) you might consider bundling all those changes together in a Process Wizard.
- You can update customer statuses automatically through Premium Webhooks. Just have them send a PUT request to the customer endpoint.
Data
There are two database tables that hold customer status information:
- The customer_status_entity table holds records for each of the statuses you've created at the tenant level.
- The customer_entity table holds records for individual customers, and the status column is where the customer status is saved.
What's Next?
From here, you may be interested in a few other topics:
- You can read about all of our other labeling options, like loan statuses and portfolios, in our article Labeling Types.
- For a more in-depth break down of how those options compare, check out Comparison of Loan Tagging and Grouping Options.