5 Steps to Documenting Process
These are technical notes I compiled while studying using Trailhead, Salesforce's free self-learning portal.
- Presenter is Melissa VanDyke, manager of Salesforce team at Orbitz Worldwide in hospitality industry
- Requests to admins always start with “Is it possible to…”, and admins' response is generally “Yea, we can do it.” But internally admins are generally squirming/panicking. Admins can generally figure it out, but the path from A to B can be a bit convoluted and nonlinear.
- Purpose of this presentation is to give you a methodology for implementing a new process into Salesforce from a documentation and requirements gathering perspective
- This methodology helps to prevent the panic step
- This methodology helps to prevent the panic step
- These steps are appropriate for large updates to Salesforce that could accurately be described as a “Project” - simple change requests do not need all this documentation
Step 1: Personas Identified (Gather the Troops)
- Identify the business owner(s) and subject matter expert(s) (person currently working the current process), which may be people from multiple departments, and executive sponsor
Step 2: Plan the Kickoff Meeting (Set Expectations)
- Write an Agenda for the meeting
- Schedule the kick-off meeting
- Include the agenda/plan in the invite to set expectations
- Start the meeting by explaining that you are there to help them solve this problem, and to do that you must know what they know about their process
Step 3: Document Current State (Mind your PB&Js)
- During the kickoff meeting, keep track of PB&Js:
- Personas (Troops):
- SME vs Super User
- Business Owner vs Executive Sponsor
- Example: Business owners/SMEs might be a “Revenue Management Manager” or a “Sales Director,” each of whom would likely bring one or more super users (people actually doing the work) to the meeting
- Bombs (user pain about the process):
- Lots of work-around processes
- Lots of pain and spinning of wheels
- Represent bigger process issues that need to be talked about
- Major use-case user pain we are designing for
- Example: Sales Team Pain - 3 email addresses to keep track of, losing track of pending request status, no visibility/summary history, significant email churn
- Jams (Salesforce Platform):
- Workflow Rules with Email Alerts/Field Updates
- Formula fields (to display “action items” on a report)
- Any automation/functionality you can build easily
- A solution we can implement easily as we go because it is readily available on Salesforce
- Example: RM Team Pain - no visibility/status history, SLA tracking is impossible, I need reports and dashboards
- Example: knowledge transfer when people leave the company, new reps have to spend a lot of time digging through files, knowledge loss since much was in emails
- Example: need to notify a different department when a task is complete, which can fall through the cracks because it is a manual process
- Personas (Troops):
- After kickoff meeting, document the current state then send via email for review
- Example of a documented process shown above, presenter creates these documents in PowerPoint
- Next:
- Gather feedback if any and adjust as necessary until everyone is aligned
- Gather field/validation rule requirements and examples of current requests to get started
Step 4: Proposed Future State (Ideal State)
- Next, create documents about the proposed future state:
- Define the ideal future state
- Identify the best way to improve existing process
- Clean up the bombs and jams with Salesforce functionality
Step 5: Planning and Approvals (Trade-offs and Buy-in)
- Next, finalize the scope and ensure alignment:
- Follow through and follow up
- Communicate expectations of deliverables and timing (what will get done by when)
- Make sure you have buy-in
- Keep communicating during the build process