Case Studies

Here are a few different examples of how we’ve helped our clients solve their problems. Read on to find out.

Reporting Nightmares

Problem: Technical Institute, Inc. provided online training & certification for companies in the skilled trades. However, their online training platform had very limited reporting functionality to provide to leadership at their customer companies (usually a Training Director). All progress reports had to be pulled manually by Technical Institute, Inc. and then individually emailed to the various training directors at these companies. Pulling reports was a cumbersome and time-consuming task for employees at Technical Institute, Inc., meanwhile the training directors had to wait sometimes weeks between report updates. On top of that, the reports were just raw CSV files of difficult-to-comb-through data, making it a hassle for the training directors to actually review and understand which of their employees were (or weren’t) making progress in their training. This provided a subpar customer experience that reflected poorly on Technical Institute, Inc.

Technical Institute, Inc. needed to spend less time delivering the progress reports and they needed the reports to provide actual intelligence, not just rows of data.

Solution: We knew that Technical Institute, Inc. already maintained Contact records of all trainees in Salesforce. So first, we created an API connection between the training platform and Salesforce. Then, we developed apex code and a database structure in Salesforce so that, every night, Salesforce pulls hundreds of thousands of rows of data from the training platform and compiles it, connecting the training data to each trainee’s Salesforce record. From there, we established a connection between Salesforce and Power BI and created easy-to-read Power BI dashboards where the training director can navigate all of their employees’ training progress. Training directors could now pull up their training reports on-demand, in real time and easily assess employee progress. And Technical Institute, Inc. no longer had to spend hours and hours delivering reports. It was a win-win!

Complex Customer Hierarchy: Subscription Struggles

Problem: National Service Provider provides services to companies across the country. Part of their service offering included access to content in a portal on a subscription basis. Login access to portal content was automatically determined based on whether or not the Contact had an “activation” field marked on their related Account. The problem lied in the way subscriptions were processed/tracked: Subscriptions were tracked not on each customer’s individual contact record, but on the related account record because subscriptions were purchased by the companies as a whole. National Service Provider maintained hierarchies of Accounts: accounts might have a headquarters location, subsidiary locations throughout the US, and even more individual locations clustered below them in the hierarchy. Each year, National Service Provider customers renew their subscriptions at the headquarters level. But because access was determined by a Contact’s immediately related Account (not the parent or grandparent record), National Service Provider employees had to update an activation field on the headquarters account record, the subsidiary records, and then the individual location records below them. There might be dozens or hundreds of records to update one by one. On top of that, this manual process introduced the opportunity for human error and if an Account record was overlooked, any related Contacts (that is, the employees at that location) would not have access to their online resources. This meant that National Service Provider spent a long time processing subscriptions and, if human error resulted in any of those hundreds of accounts accidentally being overlooked, some customers might not be able to access resources they paid for (or on the flip side, they might continue to receive access they didn’t renew a subscription for).

Solution: We created an automation within Salesforce so that when the Headquarters account was updated, each child account below it received the same activation/deactivation field update. Then, any child accounts below that also received the same update. This was future-proofed so that if any additional levels were later added in their account hierarchy, the automation would look for them and ensure it updated as many account levels as exist. This saved National Service Provider hours upon hours of mind-numbing processing time (happier employees) and ensured all individuals were getting the access that their company purchased (happier customers) — and, equally important, that they weren’t getting access they didn’t pay for.

Trouble Tracking Tasks: Leads? Contacts? Accounts?

Problem: Sales Company United was using Salesforce’s Activities tool to track sales efforts on both their Contacts and Leads. Because their product was purchased by individuals and not by the entire company as a whole, Contacts who were actively buying and Leads had not yet purchased anything might very well be employed by the same company (the Account). However, Accounts by default only showed related Contacts, not related Leads. They wanted Leads to also show on the Account record, including any related Activities.

Sales Company United’s Salesforce lower-tier licenses limited our ability to make customizations to the Activities tool itself. Sales Company United was not in a position to upgrade to a higher-tier Salesforce license.

Solution: We created two record types for Contacts: a Lead type and a Contact type. This would deprecate the “out-of-the-box” Lead object. For the new “Lead” record type, we mimicked the look of the old Lead object, including the Sales Path visual that their sales reps were used to seeing. When a Lead reached the point in the Path that it was converted, an automation would convert it to a Contact record type, which would update its page layout to look more like the Contact records the reps were used to seeing. On the Account record, we ensured that the Contact related list included the information for whether the “contact” was a Lead or a Contact. And because they were all stored in Salesforce under the Contact object (whether or not it was denoted as a “Lead” or a Contact), the Activity information was displayed in one easily reviewable aggregated list. We also created reports that filtered on the record type (a report for just Leads and a report for just Contacts). We advised the Sales Company United that the out-of-the-box Lead object was deprecated and trained users on the new methods and the benefits of the changes.