SAP
We want to get away from end-users constantly calling our Reference Managers because it promotes a reactive work environment. So we push the latest, ready-to use, reference assets to our salespeople.
Scott Acheson
Director SAP Customer Central - SAP
How to Deploy a Customer Reference Application for Your Sales Team
Introduction
SAP has a very large and sophisticated reference program with over a hundred people in the department. There are lots of variables, like regions, personalized settings etc. Scott's job is to manage all complexities and to turn it into a system that can be used globally across all regions and across all of our different stakeholders. SAP averages approximately 40,000 references and about 5,000 collateral searches per month. There are about 20,000 reference profiles on file, representing around 7,300 reference customers worldwide. From a systems development and deployment perspective, it’s a challenge to satisfy hundreds of administrative users, let alone the 66,000 employees that need to access our reference information.Objective
The primary goal for the mobile application was to provide our references to SAP account representatives wherever they work. No doubt, industry-wide there are changes in the way that stakeholders use and access reference assets. And what we found is that they’re all moving to a mobile space. Yes, they have laptops, but they don’t use them. Instead, they rely mostly upon their iPads. So we wanted to provide a self-service tool on their iPads where they can get reference information. The self-service aspect of that is pretty important. That’s one of the drivers of why we’re pushing our assets to the end users.Solution
At the core, there are four ways that AEs use our reference content along with the application functionality needed support. They needed a self-service way to list customers in a region by product or by this industry. Today, the app allows users to get this data themselves. With a few clicks, they can generate charts and graphs for their use. The 4 main ways:- Generating customer lists and reference statistics/charts—Our users constantly ask us for numbers about our program. What drives this need are the emails that our reference managers are bombarded with that say, We’ve found that in practice, these stats and charts are being used as a sort of collateral all its own. So for example, when an AE is with an automotive customer, they can bring up a chart and say, “I’ve got 100 automotive references, and fifty reference assets.” And it speaks to the volume of experience that SAP has in that particular area.
- Promoting the newest reference assets—Creating reference assets is a lot of what we do. But if people don’t use them, it’s a waste. So what we do here is to advertise the 20 latest and greatest, which we refer to as the “newest” assets. We push that info to users. However, we allow them to set up preferences so that they only receive, for example, banking industry assets if that’s what’s important to them. A note on the GUI. I always thought that the iTunes music art carousels were pretty cool. So to give our app more appeal, I had them present our newest reference assets in the same way.
- Searching for specific assets—Our users consistently search for specific pieces of content to meet their needs. To enable that functionality, we developed a Google-like search capability. Today, the AEs can find what they want and then save those assets locally to their iPads.
- Requesting a reference activity—Often, an AE or field rep needs a live reference. Maybe they need help closing a sale, or maybe they need a customer to speak at a Gartner event. To meet this need, we incorporated a very simple form into the app. All they have to do is fill it out and we process it from there.
Learned Lessons for Success
Szych Consulting Inc. has worked with SAP for years and in collaboration helped them complete the mobile application project. The size and scope of this endeavor added to the complexity of the project and there are some of the lessons learned:
- Don’t underestimate the complexity of keeping it simple One of the main goals in creating a mobile app is to make it very, very simple to use. So simple that there’s little or no training required for your AEs. They need to be able to download, launch and use its core functions without any subsequent information or training. The goal is to create a useful tool for your stakeholders. Not to create a huge drain on your resources by having to provide a lot of user support. To meet this standard, it’s important to plan sufficient time to simplify your app design and to gain consensus among multiple constituents. That’s essential when working with complex granular information and multiple source systems. One part of that is to do what SAP did and find out what’s most important to your AEs. That exercise will allow you to cover the needs of the majority of your users. Yes, you’ll still want to embed some expert user capabilities for your power users. But, you’ll want to keep the core navigation path simple to satisfy the bulk of your user base. And because you want your stakeholders to use the mobile app, you want to allow users to configure their own preferences. That way they can “make it their own.”
- Enable both push and pull content delivery methods Both methods have their own strengths, which we’ll illustrate with a couple of examples. An example of an asset push capability would be to link your mobile app to your sales cycle. This allows you to push the right assets to AEs at the right time. A good example of a pull feature would be the inclusion of a really simple Google-like search. When AEs need an asset they need it quickly and this functionality satisfies that desire.
- Plan for change. Another consideration is the need to future-proof your app. The mobile space is changing so rapidly that you need to incorporate the flexibility to adapt to that change. Certainly, you can only make a decision as good as the information that you have at the time. But you have to make sure that you get the best information you can by gathering the right people together, getting a consensus, and then committing to a course of action. Lesson Learned #4: Look at the TCO. It’s important to avoid budget “gotchas” by taking everything into account. That means looking beyond the development costs to include the costs to implement and support various devices. There are also tactical considerations. Like deciding to use HTML5 so that your app can be device agnostic, versus choosing to create a device-specific app.
How to Deploy a Customer Reference Application for Your Sales Team
Introduction
SAP has a very large and sophisticated reference program with over a hundred people in the department. There are lots of variables, like regions, personalized settings etc. Scott's job is to manage all complexities and to turn it into a system that can be used globally across all regions and across all of our different stakeholders. SAP averages approximately 40,000 references and about 5,000 collateral searches per month. There are about 20,000 reference profiles on file, representing around 7,300 reference customers worldwide. From a systems development and deployment perspective, it’s a challenge to satisfy hundreds of administrative users, let alone the 66,000 employees that need to access our reference information.Objective
The primary goal for the mobile application was to provide our references to SAP account representatives wherever they work. No doubt, industry-wide there are changes in the way that stakeholders use and access reference assets. And what we found is that they’re all moving to a mobile space. Yes, they have laptops, but they don’t use them. Instead, they rely mostly upon their iPads. So we wanted to provide a self-service tool on their iPads where they can get reference information. The self-service aspect of that is pretty important. That’s one of the drivers of why we’re pushing our assets to the end users.Solution
At the core, there are four ways that AEs use our reference content along with the application functionality needed support. They needed a self-service way to list customers in a region by product or by this industry. Today, the app allows users to get this data themselves. With a few clicks, they can generate charts and graphs for their use. The 4 main ways:- Generating customer lists and reference statistics/charts—Our users constantly ask us for numbers about our program. What drives this need are the emails that our reference managers are bombarded with that say, We’ve found that in practice, these stats and charts are being used as a sort of collateral all its own. So for example, when an AE is with an automotive customer, they can bring up a chart and say, “I’ve got 100 automotive references, and fifty reference assets.” And it speaks to the volume of experience that SAP has in that particular area.
- Promoting the newest reference assets—Creating reference assets is a lot of what we do. But if people don’t use them, it’s a waste. So what we do here is to advertise the 20 latest and greatest, which we refer to as the “newest” assets. We push that info to users. However, we allow them to set up preferences so that they only receive, for example, banking industry assets if that’s what’s important to them. A note on the GUI. I always thought that the iTunes music art carousels were pretty cool. So to give our app more appeal, I had them present our newest reference assets in the same way.
- Searching for specific assets—Our users consistently search for specific pieces of content to meet their needs. To enable that functionality, we developed a Google-like search capability. Today, the AEs can find what they want and then save those assets locally to their iPads.
- Requesting a reference activity—Often, an AE or field rep needs a live reference. Maybe they need help closing a sale, or maybe they need a customer to speak at a Gartner event. To meet this need, we incorporated a very simple form into the app. All they have to do is fill it out and we process it from there.
Learned Lessons for Success
Szych Consulting Inc. has worked with SAP for years and in collaboration helped them complete the mobile application project. The size and scope of this endeavor added to the complexity of the project and there are some of the lessons learned:
- Don’t underestimate the complexity of keeping it simple One of the main goals in creating a mobile app is to make it very, very simple to use. So simple that there’s little or no training required for your AEs. They need to be able to download, launch and use its core functions without any subsequent information or training. The goal is to create a useful tool for your stakeholders. Not to create a huge drain on your resources by having to provide a lot of user support. To meet this standard, it’s important to plan sufficient time to simplify your app design and to gain consensus among multiple constituents. That’s essential when working with complex granular information and multiple source systems. One part of that is to do what SAP did and find out what’s most important to your AEs. That exercise will allow you to cover the needs of the majority of your users. Yes, you’ll still want to embed some expert user capabilities for your power users. But, you’ll want to keep the core navigation path simple to satisfy the bulk of your user base. And because you want your stakeholders to use the mobile app, you want to allow users to configure their own preferences. That way they can “make it their own.”
- Enable both push and pull content delivery methods Both methods have their own strengths, which we’ll illustrate with a couple of examples. An example of an asset push capability would be to link your mobile app to your sales cycle. This allows you to push the right assets to AEs at the right time. A good example of a pull feature would be the inclusion of a really simple Google-like search. When AEs need an asset they need it quickly and this functionality satisfies that desire.
- Plan for change. Another consideration is the need to future-proof your app. The mobile space is changing so rapidly that you need to incorporate the flexibility to adapt to that change. Certainly, you can only make a decision as good as the information that you have at the time. But you have to make sure that you get the best information you can by gathering the right people together, getting a consensus, and then committing to a course of action. Lesson Learned #4: Look at the TCO. It’s important to avoid budget “gotchas” by taking everything into account. That means looking beyond the development costs to include the costs to implement and support various devices. There are also tactical considerations. Like deciding to use HTML5 so that your app can be device agnostic, versus choosing to create a device-specific app.
Results
Provide metric based results to references
Automatically promote the newest reference assets
Enable searchable reference assets
Reference request workflow
