Future Integrations of Sales Force Automation Solution

Sales Force Automation customers can be broadly categorized into three stages of the automation hierarchy depending on the end objective of their SFA implementation – Beginner, Intermediate and Advanced. If the sole purpose is to track field team’s basic details such as daily attendance time, number of calls, whether they are actually visiting the outlets or not, we can classify that customer to be at Beginner stage. At the next level when customer starts tracking business related data such as orders for the day, outlet wise sales, campaign execution status in merchandising deployment, they have eventually moved to the next level which is Intermediate. A customer can be categorized at Advanced stage when at the enterprise level they have a robust IT strategy that outlines complete sync among all IT systems with 100% data consistency. For example, the client would like distributor stock data to flow from DMS to SFA so that the sales person can have a complete visibility of current stock while taking order; or they may want that any change in master data in the MDM system should be automatically synchronized in their SFA solution.

While it is understandable that one cannot directly jump to the Advanced stage and it’s a journey that the customer must undergo, there must be a long-term vision to reach at that stage. Hence, irrespective of the current end-goal of the SFA implementation, one must ensure that the solution they are opting for can support them in the long run when the objectives will evolve. That’s where it becomes extremely important to select a vendor / solution which is capable enough to seamlessly execute all the integration requirements that might come up either in the near future or at a later stage. As we have served numerous customers with variety of integration requirements over the years, we are listing down some important factors that one must check before finalizing any SFA solution:

An API-ready Solution: There is no doubt the exact detailing of integration requirement (such as which business transactions to be integrated, data mapping logic etc.) will vary from customer to customer. However, an SFA solution provider must have some basic APIs ready for the obvious scenarios such as fetching daily order quantity by SKU code and customer code. It not only ensures a quick integration and low development cost, it also provides a significant confidence booster to the client as they know that the vendor they are dealing with have their basics perfect.

Flexibility in Integration Approach: While there may be standard best practices of integration, a customer may have some limitation in following the best approach because of some legacy system constrains or otherwise. For example, a client may still prefer SOAP over REST APIs. Or for that matter, they may still want to follow FTP based flat file data transfer because their legacy systems are still not compatible with SOA (Service Oriented Architecture). So, it’s very important that the SFA vendor has flexibility and capability in adopting any approach depending on customer need.

Integration-friendly Data Structure: What if you come to know after the implementation is over and adoption has picked up that the SFA solution you have selected doesn’t have a backend data structure which can accommodate your legacy system codes for basic master data entities such as customer, sales rep or SKU? A big set-back for sure, but most importantly you now have no clue how do you make all your systems in sync. So, it’s only prudent to thoroughly check whether the backend data structure of your SFA solution can cater to all your integration requirements in future.

An implementation team which understands integration: Even if your SFA solution has a perfect architecture, data structure and flexibility, which can ruin the integration is a faulty data mapping exercise. This is something to be done by stakeholders of both the system and hence implementation team of your SFA vendor has a huge role to play. They should not be just expert of their own system, they must also understand the data and business need in depth and capability to drive a discussion involving different parties. And finally, they must have enough experience in managing such integration in past.