Customer end user satisfaction is everything. Thinking back to my days as a SaaS CMO in both private and public companies, in an agile environment, we’d go through a very rigorous development pre-process to ensure a reasonable outcome for a minimally viable product.
As a company matures, strategy changes. Infrastructure supporting the strategy changes. Business process changes to better support customers. The need to integrate more systems together to have a better customer experience changes. With all these macro changes, a rigorous process to support these internal system changes must be put in place.
We typically see a greater need for methodical change in Salesforce than that of Marketing Automation because Salesforce impacts how every user in the company can operate. Getting a system level change wrong in Salesforce is VERY visible INTERNALLY; getting something wrong in marketing automation is VERY visible EXTERNALLY. Each of these scenarios impedes a good end user customer experience.
Skipping steps in a process to drive new features or product creates visible customer errors, costs sales & marketing productivity, and undermines organizational confidence. Yet so many companies with executive leaders often overlook the value of taking a methodical approach within their own systems (Salesforce, marketing automation) hoping to speed the process. Eager and impatient for results, an executive wants to jump right to the outcome. While I too was a former impatient executive, I’ve come to learn jumping to the outcome involves significant organizational and productivity risk.
In our experiences with Salesforce.com and systems that connect to Salesforce, the companies that are best in class also follow a rigorous 5 step process before rolling out change.
- Requirements definition and system design
- Architecture, set up, customization – sometimes in a sandbox, sometimes in production
- User Acceptance Testing
- Make iterations / round of revisions – repeat steps 1-3 as needed
- Launch, training, and documentation
In step 1, requirements are defined and a system is designed on paper (eg powerpoint). This gives all parties the opportunity to do ‘what if’ analysis before designing in system, and gives the ability for organizational change management buy in. It’s the least risky step yet the most valuable to do of the five steps, to ensure a successful outcome.
In step 2, once the requirements are signed off, then design can take place within the system – in some cases this design is done within a sandbox (eg Salesforce sandbox) to minimize the risk of change. In other cases, change is made right to production.
Step 3 is often overlooked. When an outside agency or any party is building software or configuring systems, going through a rigorous test process ensures minimal mistakes are made. While one would expect the configuration itself to be accurate, users often time see edge use cases not readily apparent when diagraming things out on powerpoint.
Feedback is acted upon in step 4. If new findings arise in step 3, now is the time to remediate issues. This may require repeating steps 1-3 but only if a substantial change is needed. Typically, minor point changes are needed at this stage.
The final step involves launching the changes and training the trainer or training the end users on what to expect on those changes. This ensures a consistency in the organization, rather than just one or two people knowing about the change. Documenting the change is also helpful.
When these steps are taken, you can assure your internal stakeholders are happy as your end product will be more accurate.
When business needs change, what is the process your team uses for system change to support the business?