Many organizations struggle with providing unique user experiences that help different business units in different geographies operationalize their business for the specific needs they have. In other words, one-size-fits-all centralized solutions do not cut it, and individual groups increasingly need to augment core system data to meet the demands they have to manage their customer life cycles in unique ways.
Enter the last mile data management solutions. The “last mile” is a term borrowed from the telecommunications and logistics industries, and it refers to that part of the solution that lies closest to the end user. In Salesforce deployments, think of it as the green box in this image:
The last mile involves distribution of information to a great number or widely separated end users or endpoints. Those users or endpoints are typically diverse - so delivering data management experiences to an AMER rep is different than a regional manager in Switzerland.
The biggest cause of system failure is low user adoption and its corresponding impact on data quality. From our experience implementing solutions in thousands of organizations, focusing on the last mile holds the most promise for implementing business processes at scale so that they meet the unique needs of specific user groups, thus increasing the likelihood of user adoption success.
How to Implement Last Mile Solutions
Implementing last mile data management solutions should follow 8 principles. The first 4 are presented here. Sign up (etc. etc.) to read all 8.
Reusable solutions in data management systems means they have the potential to be reused for many use cases. These solutions include code that is generically written so it can be reused for new use cases (unfortunately, a lot of Apex and Visualforce out there isn’t written this way), or applications that can be easily configured to meet new use cases.
Here we have an example of a screen in GridBuddy which enables admins to configure efficient data management experiences for an any multi-object or multi-record use case. This means GridBuddy can be configured for tailor-made user experiences at the last mile, whether it’s for different geos that have to manage opportunities in their own ways, or account management and renewal teams who work with account related data in different ways to conduct different tasks at different stages in the life cycle.
2. Smart, Efficient Consumption
In data management systems, things usually get bogged down because of performance. Smart and efficient consumption means being more focused in how we consume data per use case. It is not necessary to bring back all 50,000 rows for an end user in most cases. Rather, apps should be designed to retrieve only what users need at any given time. This helps users cut down the noise and efficiently focus on what is most important for them to do next.
With smaller data sets, apps can free up their their query cycles to combine data in the ways end users need to see (for example by cross-referencing many objects together to give data more meaning and context), instead of having to worry about performance considerations that traditionally limit users to data sets that are too simplified (e.g., single-object data sets).
3. Integrative and Modular
This principle says that anything we add on must have capacity to interface effectively with everything that was there before.
A good example of modular solutions in enterprise data management systems are apps on the Salesforce AppExchange. These apps are made to work with your existing Salesforce instance and its data. They can be installed in a few button clicks, and individual setup nuances aside, take a lot of the legwork out of ensuring they work with your existing setup. These apps provide a great way of not “reinventing the wheel” when implementing solutions to manage the customer life cycle by using additive plug-and-play solutions to solve gaps in the core Salesforce system.
Another modular concept has to do with how you grow your data model over time. Some of the smartest enterprises out there including NetApp introduce new, purpose built objects that hang off of core “enterprise objects”, like the Account and Opportunity, in order to support incremental process needs. The reasoning is clear: so many systems and user groups depend on the core enterprise objects that changes to these can introduce ripple effects. It’s also not very good data modeling to flatten all of your fields on these objects (e.g., you know you probably have a problem with this if you have over 300 fields on your Opportunity object).
For example, if you have an SDR team that is making calls, you might have a “Qualification” object that is specifically geared towards capturing information related to the qualification questions they ask. This object can be associated to a Lead, a core enterprise object that many groups including marketing, SDRs and AEs depend on, and therefore should be touched lightly. This object can only be visible to those who need to interact with it. Likewise, when a Lead becomes an Opportunity, you might have a “BANT” object that AEs can use to capture the budget, authority, need and timeline questions that are specific to their calling activities.
4. Relatively Simple To Understand
Another way of saying this is that things should just work.
In business process automation, simple to understand means when I look at a process, I know what it does. It speaks to me. It walks me through what I need to do. Most users don’t care where data is stored; they just want to be able to do their work productively, and work on what is relevant to them. This means don’t expose raw components to users that they don’t understand and tell them that’s their business process.
This image shows an example of a “single-object user experience” which violates this principle. Notice that the business process is articulated in terms of raw system components. Your users may or may not know what these mean.
This diagram below shows an example of how we need to abstract those raw system components into the language of the business. Notice how the business process is articulated in a language that users understand because it corresponds to what they have to do.
But wait, you’re not out of the woods yet. There’s just 4 more principles you need to follow to make sure you’re rolling out business processes for managing the customer life cycle that won’t come back to haunt you.