Our Salesforce Solutions Team product owner did not want to purchase more Salesforce seats. But Admin Services was pretty sure that they would need direct access to our new B2B CRM so that they could access the same information and take notes in the manner they were accustomed to with the old CRM, known as SalesLogix.
Fortunately, the Application Delivery department head asked me to join the conversation and help map the problem space and an answer to the question:
do we REALLY need to purchase more Salesforce seats for Admin Services?
My process
My special sauce quick service design process that is particularly helpful with internal workflows:
- Map the current state: how is Admin Services currently using SalesLogix and why?
- Map the desired future state: can we map out a new process/workflow for Admin Services that doesn’t use the new CRM replacing SalesLogix?
- Test with users: can Admin Services do what they need to do in a proposed new workflow?
- Iterate as needed!
Step 1: Map the current state (“discovery”)
My organization is not great at documentation. By the time I reached the Admin Services employee who helped me map out the current state workflow that needed to be changed, she had already explained some version of this process to multiple people. I wanted to make sure that stopped happening as a sign of respect to her time and also to make sure that documentation captured the current information and stored it for future reference/use.
I even created a template of “use case documentation” to show other POs how they could do this in the future themselves without me:
Notice that this is method for documentation AND note-taking.
Building blocks of creating current state workflow/process visualizations:
- Notate when a digital document versus a paper document is created.
- Use a specific shape for decisions when they alter the subsequent steps of the process.
- Use colored sticky notes for yourself and others working on the service design to differentiate observations, questions, and pain points that you want to flag.
- I also documented some dos and don’ts of how best to leverage this process:
| DOs | DON’Ts |
| Map use cases across ALL platforms and applications used | Don’t document use cases AFTER design and development work has begin if at all possible |
| Just document the current state | DON’T ask about what the user “wants” – conversation should focus on existing state and any pain points they currently experience |
| Capture pain points | At this point in the process, don’t ask about or start to sketch out any future state possibilities (“solutioning”) |
| Make not of opportunities for improvement | |
Here’s the resulting current state flow that I captured. Feel free to take a look yourself in LucidChart because the screenshot I put here will be difficult to view.
Unexpectedly, this step ended up including me going to the desk of one Admin Services user to view and document the paper, handwritten documentation that they were using in their current process that had not come up in conversation yet. Handwritten notes in the margins of paper documentation were very important to those users because the digital version of those documents were locked down by Legal.
Step 2: Future state
Analyzing this current state visualization with the PO of the former SalesLogix product, we concluded that there wasn’t anything that Admin Services needed to access or store in the new CRM system to meet the goals of this current process. Therefore, no reason to purchase additional Salesforce “seats”. Huzzah!
But we still needed to get the Admin Services users on board and make sure they felt the same way. So, I mapped out a possible future state. You’ll never guess what we replaced SalesLogix with…. A shared Microsoft Excel document. Yep.
View the first iteration of my solutioning to see where I started.
After walking the SalesLogix PO through my version one of solutioning, he identified that past data that could be useful could be exported from SalesLogix into an Excel document that could serve as the foundation of the new document that the updated future state process would rely on.
Here’s the final future state process I landed on. Time to test it out with Admin Services users and see what they think.
Step 3: Test it out
I created the new Excel shared document and organized it by state and funeral home name. We walked the Admin Services manager through the new workflow and got her approval that we covered everything. We handed off the new document and waited to hear if there were any issues. In particular, they needed to transfer their own handwritten notes from each individual packet to the group shared Excel document.
Step 4: Iterate?
A few months later, I reached out to the Admin Services crew to check in. Ominously, a user wrote back, “we made it work”. Not a ringing endorsement. I asked what she meant and she wrote back via Teams:
Yes, I modified it a bit to work for us but other than wishing we would have asked for a few more things to be pulled we got the most important information we needed from it.
What’s my takeaway from that? We should have iterated a bit more. One or two more meetings with different Admin Services users who complete this work might have also filled in some gaps to ensure that the ending process reflected the whole user group’s needs.
Impact 💸💸💸💸
We saved multiple thousands of dollars in Salesforce seats (I’ve been asking for a more exact number but alas my Salesforce Support team PO has not gotten back to me). Some other positive impacts of this process change:
- All Admin Services employees are using the same shared Excel document via our Shared Drive to access and store notes instead of individual paper documents.
- Crucial information was transferred over from the previous SalesLogix system instead of being lost.
- No new application or log in process added to Admin Services work load.
- Because the new shared Excel document is easier to access and edit, it takes less time to complete the process from beginning to end.
