July 25 2021
Building Deep, Scalable Customer Relationship Management Tools
Retrospect.com is a web application that happens to include a website.
With Retrospect.com, visitors can learn about our data protection suite in eight languages. Customers can log in to the support portal to view their order history, license codes, and support tickets as well as access personalized upgrade options in the upgrade wizard. Partners can log into the partner portal for client order history, personalized sales campaigns and quotes, partner tools and collateral for their sales territory, trainings and printable certificates, and support tickets.
I built these CRM tools incrementally over the course of five years based on consistent communication with Sales and Support to address their pain points with customers and partners. Each tool has enabled Sales, Marketing, and Support to efficiently deliver deep customer experiences at a scale they could not handle without a far larger team.
I’ll first walk through the stack and feature set, and then I’ll discuss the implementation tradeoffs.
CRM Stack
Let’s walk through the stack:
- Web framework: Ruby-on-Rails
- Underlying CRM: Salesforce
- CRM Integration: Restforce Ruby gem
- Authentication: Devise
- Database: Postgres
- Email: Twilio SendGrid
- Deployment: Salesforce Heroku
- Source Control: GitHub Enterprise
Localization
Retrospect is used by homes and businesses in over 100 countries, and the software is localized in six languages. To enable this global reach, the website is localized into English, German, Spanish, French, Italian, Japanese, Latin America Spanish, and Portuguese along with AU and UK English regions.
On any page of Retrospect.com, you can scroll to the footer and click one of ten language links, and you will be taken to the same page but in that language. The app automatically chooses the language based on your browser settings.
The actual pages in GitHub don’t contain English or Japanese. Instead, they have code to translate keys into text strings, based on the language you have selected. Retrospect.com includes over 10k strings, stored in dozens of YAML files and versioned by GitHub.
Even our knowledge base and documentation live in the website and support different languages through the same process, although both use the Asciidoc format instead of HTML/Erb or Markdown.
Read more about localization at scale in “Rails internationalization at scale”.
Support Portal
Customers can sign up for the support portal, and that portal account is automatically associated with their own Salesforce account based on their email. From the portal, customers can see the latest news along with pre-release information if they are part of our beta program. Along the top, they have easy access to their licenses, support tickets, and referrals.
The “Licenses” section shows their purchases including licenses and their upgrade options.
The “Support” section lists all of their support tickets. Customers can create new tickets, update them, and view the ticket history, including attachments.
Internally, we have used Salesforce Cases for tracking support tickets since 2011, but customers did not gave access to them until we created the support portal. A great benefit of continuing to use Salesforce as the backend is Support did not need to change their workflow.
With a self-service portal, customers are able to look up license keys and track support tickets, leveraging our existing Salesforce data and Support’s existing workflow.
Partner Portal
Partners can sign up for the partner portal, and that portal account is automatically associated with their own Salesforce account based on their email. From the portal, partners can see the latest news including pre-release information, their certification status, and their regional sales rep’s contact details. At the top, they have easy access to enablement tools, pipeline, client base, and support tickets.
As a CRM, the portal lists client details including purchase history, licenses, and upgrade options. Distributors can see their reseller network as well. For enablement, the portal has a variety of tools:
- Lead pipeline
- Deal registration for resellers and distributors
- Personalized email campaigns with embedded logo and contact information
- Partner collateral
- Pre-release product information
- Partner trainings
- Personalized training certificates to download
Our sales team is able to scale the number of partners they enable by utilizing this self-service portal to help resellers and MSPs all over the world take advantage of these personalized tools and incorporating our existing Salesforce database.
Upgrade Wizard
The upgrade wizard, available at Retrospect.com/upgrade, supports upgrade options, upgrade license fulfillment, annual support and maintenance (ASM) license fulfillment, and even recent upgrade fulfillment.
Each version of Retrospect has a new set of license keys for the many editions and add-ons included. Customers can type in a license code and view their upgrade options, but it supports far more as well.
Because of our channel business model, customers can purchase upgrades and support renewals without first validating that they own the software. They can buy a product and receive a license code for it, but the code does not license the product. Instead, the code tells us what they bought, and we verify that they are an existing customer before issuing a license fulfillment with a functioning license code.
Our Sales and Support team used to do this manually in Salesforce, creating new “zero-dollar” opportunities, adding products and licenses to them, and then sending an email fulfillment to the customer. Thousands of times.
The tool automates these manual tasks and saves thousands of hours per year for the company.
The upgrade wizard is not inside the support portal to make it more accessible. Sales and Support frequently direct customers and partners without portal accounts to the wizard, and the sign-in wall is an extra barrier. There is a clear trade off: ease-of-use versus potential piracy. You can validate a license without signing in, meaning any person could test prospective licenses until they found one without purchasing. In practice, the key space is enormous: 1m licenses per release out of 36^16 or 1 in a quintillion (8x10^18). If the issue ever arises, through Sales or Support, we can easily move it inside the portals.
Implementation Tradeoffs
When we wrote the first version of the website nine years ago, we did not have these components in mind. We just needed a website after we were spun out into a private company.
As a small team, we didn’t have a web developer in Marketing. We had engineers who knew web development. We could have created it in Wordpress, but Engineering wasn’t familiar with the tool. Wordpress felt like a CMS designed for Marketing, but we weren’t the target audience for it.
We knew the Ruby-on-Rails web framework, so the first iteration of the site used that. We needed to get the site off the ground, and Ruby-on-Rails was the quickest path.
But at a deeper level, we saw Wordpress’s accessibility to non-developers in Marketing as a limitation because of the constraints it imposed. Wordpress operated at a higher abstraction layer, and Engineering wanted to control more of the stack. Hosting Wordpress, backed by a database, was an issue too because we wanted a website versioned by GitHub. Maybe these tools existed for Wordpress at the time, but we didn’t know.
We could have taken a modular approach: the website in Wordpress, sales data in Salesforce, support tickets through Zendesk, and partner portal though Force.com. That approach would enable Sales, Marketing, and Support to manage their tools themselves and depend on a third party rather than Engineering’s bandwidth. However, it would be far more expensive, less tailored to our specific needs, and less integrated with our other tools.
For example, I built an internal tool for order processing that saves significant time every day: “Saving $100k per Year with Order Processing Automation”. I could have built it without the rest of the tools, but those tools were the reason that we had a stack for integrating Salesforce and a web app with a sign-in wall.
I built the partner portal in about two weeks. There was no incremental cost, and with its Salesforce integration, it provides a far better experience than other solutions. Development speed is an important factor.
However, long-term maintenance of homegrown tools is another factor to consider. In-house tools that teams depend on can prove to be very expensive if the developers leave and takes their domain knowledge with them.
At a previous company, a developer built a license activation server at Sales’ request to combat piracy. Three months after the developer moved on, the license server stopped working, and the entire company ground to a halt. Customers couldn’t use new licenses. It took two days for Engineering to diagnose and fix the issue. The root cause was the developer used their own credentials for various API calls, and the credentials were cleaned up after 90 days. Luckily, there wasn’t a worse bug. With a third-party service, you can offload the risks of institutional knowledge and technical debt to them.
Finally, there is the very real opportunity cost of Engineering building custom tools for other departments. We thought that the calculus made sense for Retrospect because we were a self-funded private company with a small, technical team. As part of a larger organization, the payoff is less clear unless there is an official department dedicated to development and, equally important, maintenance.
Leveraging Engineering in Sales, Marketing, and Support
Engineering can enable Sales, Marketing, and Support to deliver deep, scalable interactions with prospective buyers, customers, and partners, tailored to each departments’ needs.
But utilizing third-party services might make more sense in terms of projected revenue or savings versus price and in terms of long-term maintenance and technical debt.
The question is whether the opportunity cost is worth the investment.
