Creating a Scalable Customer Experience
How Customer Relationship Management became LhCrm™
What does “CRM” mean and why does it matter at scale?
Customer Relationship Management (CRM) has become a loaded term that can often be all-encompassing. As a result, there are many different interpretations of what “CRM” is and what it includes. But no matter the interpretation, the importance of knowing your customer remains the focus of any CRM. This is simple when companies are small and customers are few; it’s easier to build a few strong relationships. At LendingHome, for example, we never forget our first customers: we’ve named our conference rooms after the street names of houses we’ve helped to finance.
As a company scales, not only does its number of customers grow, but so does the number of interactions with every customer. Not to mention the growing number of employees communicating with customers. At that point, it becomes incredibly important to have the right tools in place, so that the company can continue to be customer-first and deliver their product effectively. In LendingHome’s case, as we were building up a large customer experience organization, we had to scale our information and processes to the point where now, every time a person gets on the phone with a borrower or investor, we know who they are and what they need from us.
Ensuring you have the right tools for the job
If you do not live in San Francisco and haven’t seen the Salesforce tower overpowering the city’s skyline, or still think that “inbound” just refers to a basketball play after a timeout, you may not be familiar with the proliferation of the various software tools aimed at helping companies improve their customer relationships. Each of these products is meant to create a process around a specific function, and integrating with these products is a build vs. buy decision that needs to be made. Here are a few questions to consider when integrating with a CRM:
- Do they specialize in something that you shouldn’t? We’ve all been in situations where we’d prefer to write whatever we need ourselves, as it can be easier to write a custom solution than integrate with someone else’s generic one. But the question is whether or not you should do this when it’s not, and won’t be, the core competency of the your company. Salesforce specializes in storing customer information in an actionable way for sales teams; Marketo specializes in leveraging that information and automating customer interactions.
- Can it accelerate the velocity of your organization beyond your engineering team? The primary benefit we’ve discovered through our integration with vendors like Salesforce or Marketo is that we’ve increased the number of channels where we can accomplish things. Our sales and marketing teams are now empowered to create new dashboards, prioritize workflows, assign cases, and create outreach campaigns without relying on engineering. So now our engineering team is solely responsible for ensuring data is consistent and synced properly.
Asking the right questions for a scalable system
It can be hard to measure “pure pain,” but LendingHome’s first integration with Salesforce may have caused more problems than it solved. Much of this was due to design choices that, while pragmatic at the time, led to problems down the line. For us, the important questions were the following:
- What should we be syncing? Initially, we allowed information to sync bi-directionally, so updates in our platform would update values in Salesforce and the same would occur the other way around. This proved to be quite expensive since we had to know information before we could do the sync, resulting in multiple queries (and multiple potential failure points). This was compounded by the fact that we made the choice of syncing on email addresses instead of properly using our platform data’s primary keys as lookup fields.
- How often will we be syncing? In addition to accounting for instances when syncing was occurring correctly, we also had to consider the error cases and the poor-quality data that accumulated as a result. As such, one aspect that we didn’t account for was how often we would need to backfill data, resulting in each record syncing again and again. Initially, we were not using a bulk API to do this work, which often resulted in getting on the phone with our Salesforce account managers, begging them not to rate limit us.
- What was the result of our syncing? As many know, the debugging process can be the most difficult part of any new integration. When we first began to do this, we would have Sentry errors routed to Slack for errors. Slowly but surely, those would pile up as we had more failures, types of errors, and more vendors to the point that they would all become noise with nothing actionable.
How we addressed these problems and created LhCrm™
As more integrations were coming down the pipeline, we did what would make any manager (or mother) proud: we added rules and boundaries to approach the issues head-on:
- Limit what you sync! In order to reduce the complexity and keep the information more consistent, we decided to limit the information that we sync, so that it would always go from platform to third party services. This simplified our code on the platform side and removed the need to do any complex querying we needed for updates. As a result, data from platform was always the source of truth.
- Queue and try, try again! To handle our syncing frequency problem, we also added transaction queues to help batch requests. A pending queue allowed us to let records pile up and leverage bulk APIs to make our requests. Next, we made moving a record from pending into the processing queue an atomic operation that prevented duplicates. Because of the aforementioned one-way syncing, we didn’t care about the order of operations either which meant that we also benefited from debouncing and limited the number of transactions we would sync at once. Finally, a failure queue would let us do retries after the fact.
- Why don’t you tell me what transaction you are trying to complete! To understand the result of our syncing, we exposed all of the details in every transaction to be visible in our loan origination platform (Figure 1). From this, we then allowed any user to search for a specific transaction, view all transactions in the pending or processing category, and manually retry any failing transactions that have occurred. This created an environment where all parties could help diagnose problems and debug issues.
To do the above, we created a separate gem, called LhCrm, that contains all of the commands needed here. Encapsulated are various services that read from LendingHome data and write to third parties, like Salesforce and Marketo, and incorporate the commands to ensure quality and seamless processing. Below is a diagram (Figure 2) that shows the relationship between the various parts of LendingHome and the commands, services, and models that exist inside LhCrm.
We designed this as a gem to create clear boundaries in our code and provide a clean interface that would be easy to maintain. In addition, LhCrm functions as a Rails Engine and allows us to incorporate unit tests, run them quickly, and write transactions to independent databases.
Through this process, we have learned that one of the most important aspects of creating a great CRM system is ensuring that there is a consistent infrastructure that syncs data accurately and reliably. By doing that, we can create leverage for all employees in our organization!
