You are reading a guide that explains how to build up your organization's Operational Knowledge. This article covers how to accomplish stage 2 in operational knowledge maturity scale.
Prerequisites
This solution guide is aimed at Salesforce consultants. You will need:
Understanding of UPN diagramming methodology
Why use process diagrams in pre-sale discovery?
Process diagrams are vital in pre-sale discovery because they visually capture the project’s full scope, making complex processes more understandable for clients and stakeholders. They help identify inefficiencies, justify costs, and reveal opportunities for additional services, ensuring that all parties are aligned on the project’s objectives.
Process diagrams mapped in UPN notation (more on that later) are particularly effective in demonstrating this by:
Highlighting Business Value: Each step in the diagram emphasizes the specific benefit, such as increased accuracy, reduced errors, and improved decision-making.
Clear Communication: By illustrating both the scope and benefits, these diagrams make pre-sales discussions more impactful and aligned with client goals.
Additionally, using process diagrams during pre-sales ensures a seamless transition to implementation phase by:
Maintaining Consistency: The same diagrams used in pre-sales are carried over to the implementation team, reducing miscommunication.
Layered Detail: High-level diagrams can be expanded with more detail during implementation, maintaining alignment with original business objectives.
Streamlined Handover: A consistent process from pre-sales to implementation ensures a smoother handover, avoiding delays and rework.
This approach ensures that the project maintains focus and clarity from the very start through to successful execution.
When to use process diagrams in pre-sale discovery?
Process-led approach should be utilized in pre-sale discovery especially in the following scenarios:
New solution implementations: When customer is implementing new Salesforce Clouds (e.g. CPQ, Data Cloud, Industries etc.), process diagrams clarify how these systems will integrate with existing workflows. For example, they help visualize existing ways of working and understand how they will need to adapt to new technology.
Multi-department projects: In cross-department implementations, diagrams ensure workflows across teams, like sales and marketing, are aligned, preventing issues during the rollout.
Multi-phase projects: When a project is expected to be broken down into multiple phases and deliverables, diagrams help visualize the ultimate destination and individual phases, making sure that in the end you deliver smooth flow across teams and functionality.
Business Process Re-design: When the business decides to completely change how they operate, and they see it as a process issue, not merely a technology issue, diagrams allow to compare current and future workflows. For instance, they can highlight inefficiencies in a sales process and show how the new design improves efficiency.
How to utilize process diagrams in pre-sale discovery?
In a consulting project, the discovery phase is all about understanding the exact requirements and scope. This understanding is crucial for providing an accurate estimate and quote to the customer.
During this phase, process diagrams should be kept relatively high-level. They are used to capture the overall flow and desired state, helping to uncover key requirements and potential opportunities.
However, these diagrams should not go into the detailed design of solutions, such as specific automation flows or user interfaces. That level of detail is reserved for the implementation phase. The goal is to gain a clear understanding of what needs to be achieved without defining exactly how it will be executed.
Why UPN is the best notation for pre-sale discovery diagramming?
Universal Process Notation (UPN) is a straightforward yet robust diagramming technique supported by Elements and used to capture a wide range of workflows.
The foundation of UPN lies in its simplicity: a single type of building block that represents an activity, augmented by flowlines indicating sequence and connections between steps. Each block in a UPN diagram answers the key questions that define an activity within a flow:
What? (the activity itself)
When? (the timing or sequence)
Who? (the responsible party)
With what? (the resources or tools used)
Why? (the outcome or purpose)
This focus on capturing verifiable outcomes sets UPN apart, ensuring that each step within a process is purposeful and measurable.
To learn the full notation and best practices with Universal Process Notation, read this guide.
Library of out-of-the-box Salesforce process templates
One of the key strengths of Elements is its extensive library of detailed business process templates tailored for different Salesforce clouds. These templates can be a game-changer during the pre-sales phase:
Accelerated Discovery: By providing a ready-made framework, these templates help quickly identify the client’s requirements and existing processes, significantly speeding up the discovery phase.
Standardization of Practice: These templates ensure that all team members and stakeholders are aligned on a consistent approach, reducing variability and ensuring that best practices are applied uniformly across the project.
Education and Discovery: The templates serve as an educational tool, helping clients and stakeholders understand the capabilities of Salesforce and identify new opportunities for process improvements that they might not have considered.
Do's and Don'ts of using process templates in customer engagement
Before we get to the implementation guide, there are a few rules you should follow:
Don’ts
Don’t Position Templates as Universal Best Practices: Avoid presenting templates as the definitive best practice for any industry or as a one-size-fits-all solution. Clients and stakeholders often view their business as unique, and suggesting that a standard template fully represents their operations can lead to immediate rejection of the approach.
Don’t Impose Standard Processes: Refrain from implying that the template represents the only way to run their business. Instead, use it as a flexible tool for discussion, encouraging stakeholders to adapt and refine the process based on their specific needs and insights. This approach fosters collaboration and ensures greater acceptance of the final solution.
Do’s
Position Templates as 'Out-of-the-Box' Processes: Clarify that the template represents how a given Salesforce Cloud functions when initially deployed. Emphasize that it serves as a starting point—a canvas for identifying what the client currently has, what they want to use, what they don’t need, and what should be augmented or changed.
Tailor Templates to the Client’s Needs: Allow the client to modify and expand upon the templates, ensuring that the final process maps accurately reflect their unique workflows and objectives. This personalization helps build trust and ensures that the client sees the relevance and value of the proposed solutions.
Implementation guide
Step 1: Create a new consulting space
First, create a new consulting space for your client. Follow your consulting practice's naming convention, e.g. '[Account name]:[project type]', like "Acme.com Org Merger".
Step 2: Copy the required template
Elements template library contains many business process templates for various Salesforce solutions, like Sales Cloud, Service Cloud, Revenue Cloud, various Industries Clouds, and many others.
When you create a new diagram, you can choose to create it from publicly available templates. Pick the business process that aligns with the solution the client wants to implement OR the business area they wish to improve.
You can also create your own, internal template library! More on that here.
Step 3: Prepare and unify the diagrams
It is possible that the customer is planning to implement multiple solutions (e.g. Sales Cloud + Revenue Cloud + Marketing Cloud) or re-design multiple processes (sales, customer service, marketing).
In that case, copy all the required templates into your space and then work on merging them together into a single hierarchical diagram. You can do it by importing other diagrams into your diagram.
Step 4: Gather key stakeholders
You need to gather the right business stakeholders in the room. This should include all the key people who perform a given business function. For instance, if you are mapping the sales process, you should get the sales team, and not members of other functions like finance or marketing.
If your organization is very large, and a business function has dozens or hundreds of employees performing the same job, then you should focus on key managers who are closest to the day-to-day operations.
For discovery workshops, it is recommended to avoid just relying on a single senior manager for a business function. That is because they tend to have a view of 'what should be happening', which is often different from reality on the ground.
Since the purpose of the workshop is to discover the current 'As-Is' process with all its inefficiencies, the workshop participants should primarily be people who are involved in day-to-day execution of the job.
If you have identified owners and stakeholders on key capabilities and metadata, you can run a stakeholder report in your metadata dictionary to produce a list of initial stakeholders.
Step 5: Run requirements gathering workshop
5.1 Amend the diagram
At this point you have an out-of-the-box business process for a given Salesforce solution or general 'standard practice' diagram for a given business function.
During the workshop, you should encourage participants to reflect on how things are done differently (or how things will be done differently) and amend the diagram to more closely resemble the customer's vision.
Here are example questions to ask during the workshop:
Example questions
Example questions
Identifying Differences:
Looking at this specific step in the template, how does your process differ at this stage?
Are there any steps in the template that are missing or not relevant to your current process?
Do you handle this activity the same way as shown, or is there a variation in your approach?
Evaluating Fit and Adaptation:
Does the sequence of steps in this template align with how your team operates?
What modifications would be necessary for this template to better fit your business needs?
Are there any elements in this template that could be automated or streamlined in your context?
Strategic Alignment:
How well do the goals of this process template align with your business objectives?
Does this process template support the key metrics or KPIs your team tracks?
Assessing Potential Challenges:
What challenges do you anticipate if you were to adopt this process template?
Are there any regulatory, compliance, or internal policy contexts we should incorporate into this diagram?
Would any roles or responsibilities need to change to fit this process?
Final Considerations:
Which areas of this template do you see as providing the most value to your business?
What support or resources would you need to implement this template successfully?
5.2 Capture desired business outcomes
The most powerful and challenging aspect of mapping good UPN diagrams is capturing clear, distinct, and verifiable outcomes on activities.
For the process to reveal useful and actionable information, we need to understand not only what happens, but why? Consider the example below:
It is common for people to think of outcomes as past-tense of the activity itself, e.g. 'Log a case' -> 'Case created'. But that does not reveal to us the business value of why do it in the first place (are we just logging cases for case-sake?) nor what are the success criteria of doing so.
Challenge your workshop participants with following questions to help reveal the clear, distinct, and verifiable outcomes after each activity:
What would happen if we didn't do the activity? What would we lose?
How would I know that Sean performed that activity? What would be the proof?
What's the difference between performing this activity well and poorly? What would be the difference in the final result?
5.3 Capture pain points and KPIs
Custom data tables can be attached to each step in the process, enabling the structured capture of detailed information, such as pain points, ideas for improvement, and expected business KPIs. These tables also function as smart, contextual surveys, allowing workshop participants to provide input in a structured manner.
Tip: You can either capture data table records in a live-worksop setting OR ask participants to fill it out asynchronously in their own time.
Proposed data tables:
Data table for capturing pain points
Data table for capturing pain points
Pain Point Description (Text)
Purpose: Provides a brief description of the pain point to clearly understand the issue.
Impact (Picklist)
Purpose: Captures the severity of the pain point on the business.
Values: Low, Medium, High
Frequency (Picklist)
Purpose: Indicates how often the pain point occurs to help prioritize resolutions.
Values: Rarely, Occasionally, Frequently
Employee Feedback (Text)
Purpose: Direct comments from employees regarding the pain point, offering insight into the issue's nature.
Priority (Picklist)
Purpose: Helps to prioritize the pain points based on urgency and impact.
Values: Low, Medium, High
Business KPIs data table for top level diagram
Business KPIs data table for top level diagram
KPI/Objective Name (Text)
Purpose: Provides a clear, concise name for the KPI or business objective related to the business process.
Description (Text)
Purpose: Offers a brief explanation of what the KPI or objective measures and why it is important for the business process.
Measurement Type (Picklist)
Purpose: Indicates the aspect of the process that the KPI or objective is measuring.
Values: Efficiency, Effectiveness, Compliance, Quality, Time, Cost
Target Value (Number/Percentage)
Purpose: Defines the desired outcome or target value for the KPI, setting a benchmark for success.
Current Value (Number/Percentage)
Purpose: Captures the current performance level for the KPI, allowing for comparison against the target.
Frequency of Measurement (Picklist)
Purpose: Indicates how often the KPI is measured to ensure timely tracking and adjustments.
Values: Daily, Weekly, Monthly, Quarterly, Annually
Owner (Text)
Purpose: Identifies the team or individual responsible for monitoring and achieving the KPI, ensuring accountability.
5.4 Capture detailed business requirements
At this point in the pre-sale discovery you have:
Updated high-level process diagrams that are aligned with customer's current or future desired state
Captured a list of pain points and desired KPIs identified in context of relevant process steps
You can now go through the process step by step, report on found pain points and KPIs, and use that information to capture detailed business requirements. These records, in Elements, represent the overarching need or want from the business (we want X so that we can Y).
Step 6: Prioritize business requirements
All business requirements captured from your diagrams are available in the central repository under the 'Changes' menu item in the main application.
You can sort them by priority, impact or other custom fields you have defined on your business requirements.
Step 7: Provide accurate quote
You have used a process-led approach to drive discovery and alignment with the client on their ways of working and business needs. This has allowed you to capture detailed list of business requirements, in context of the business process.
With the scope properly defined, you can now provide your customer with an accurate quote for the implementation services and justify any extra cost through the analysis that was done together.