Introduction
For an organization to adopt a Sales Force Automation system, or a similar one also called Customer Relationship Management (CRM), Distribution Management System (DMS), etc usually represents a significant investment and commitment that needs to be carefully managed. The successful implementation depends on the quality of the inputs and the database that will then be leveraged to build powerful analytics and deliver the desired productivity gains.
In this article, we want to highlight a few dimensions that we believe should be considered when preparing for such a change. It comes as a complement to other articles we wrote, on the dimensions to consider when purchasing a field force automation solution and how to ensure adoption of your field users.
1. Appoint a clear governance structure
The first step in a successful deployment of an SFA system is to have some key owners that are in charge of driving the project forward. It depends on the organization and the skills, but typically it should be led by owners from the IT department and the Sales Team.
It is essential that both work together, as the sales team might not have the time and background to draft clear and detailed technical specifications. A risk then is to have vague requirements leading to irrelevant implementations. The structure should be in charge of validating the specifications in the form of user stories. Other stakeholders that need to be associated with the initiative could be:
- Procurement. To structure the tendering process if applicable
- Legal and Finance. To ensure the payment and contracting are compliant with what the company processes, in terms of currency, data management, etc
What matters, in the end, is that there is alignment between all the stakeholders when deciding to roll out.
2. Consider all user personae, for the benefits of everyone involved
When listing what you need to obtain from the system, it is important to list all the user personae that will be impacted and should benefit from the new tool. As a reminder, a user persona is a typical user profile, such as the delivery person, a sales administrator, etc. As per the agile framework, a user persona has certain needs that are expressed as user stories, like “As a sales representative, I need to be able to locate the customers around me”.
One common mistake we observe is to ignore the field users or not pay attention enough to how they really work and design the system only to the benefit of the management/office users. That results in a system being seen as imposed from top-down. The success lies in the hands of the primary users, the field users, and should help them save time, not lose data, visit more clients and in the end get higher commissions. If they do not see their interest, it is quite likely they will push back at using the tool, only perceived as a waste of time which only serves the management.
The typical symptoms of this are users trying to blame the tool for having bugs or not working, and trying to not comply with the desired outcomes.
3. Ensure the tool is flexible enough to adapt to your processes, not the other way around
When assessing the different tools available on the market, try to understand how they have been designed, their architecture. If you go down to their API contracts, and the concepts used, you will understand well how they can be adapted to what you need.Keep in mind that it is quite likely that there will be changes in the future, and as such not all the requirements can be captured on day one, with 100% accuracy.
Additionally, you should inquire how much of the changes are self-service or do require the intervention of the vendor to be performed. You might rather want to invest time and resources in a solution where the knowledge can be shared and your team trained on “owning” the tool to make changes, rather than be dependent on the supplier.
4. Prioritize, to start small and iterate
Once you have a list of needs you want to fulfill with this new tool, a commonly seen pitfall is to desire anything at the same time.
We are strong promoters of the agile approach, we believe it is better to start small on a limited scope to start gathering the benefits of a first concrete experience with the users, rather than waiting too long for everything to be perfect, then to realize it is not fitting your requirements. Especially for a first-time adoption, there are many unknowns that will be discovered upon rollout.
5. Make it part of the culture
The adoption of such a tool only works if it is made a priority by the top management, if everyone understands how the organization is going to benefit from it in the long run, it will improve the relationship between the field and office users, as well as other partners, etc.
The commercial policy needs to be updated so that the remuneration of the app user, such as the field workers, or the agents using it should be tied to the performance recorded on the app. The reporting should be shared regularly with all the stakeholders internally and externally to monitor the adoption and the performance.
6. Prepare budget for updates
With time it is likely that you realize you need more features or some changes in the reporting structure. Such costs will typically be considered changes requests with man-days of work, and require some extra budget.
Ensure they are factored in the business case for constant upgrade of the solution and clarify with the vendor their change request policy.
Conclusion
Rolling out a Field Force Automation solution is not a smooth journey, it is a true digital transformation for an organization and needs to be done with close coordination among all stakeholders.
Keep in mind all the dimensions listed above to maximize the chances of success and achieve the desired gains.
_________
Subscribe to our newsletter for more insights! ⬇️
