Salesforce Consulting and Characterization
Before defining a single field,
define what the system needs to achieve.
Proper characterization connects business objectives with the technological solution. It prevents unnecessary development, reduces misunderstandings, and creates a common ground for management, users, and the technical team.
What We Map
A complete picture of the organization before making decisions
- Current state
- Desired state
- Users and stakeholders
- Business processes
- Existing systems
- Information sources
- Data quality
- Permissions and information sensitivity
- Integrations
- Success metrics
- Risks
- Priorities
Problems the service solves
What Happens When Characterization Is Skipped
Requirements that change weekly
Without structured characterization, every stakeholder pushes a different item to the top of the list. Characterization produces a single document that all parties sign off on, enabling managed change in an organized manner.
A solution chosen before the problem was defined
Sometimes an organization purchases licenses or a module before it's clear what for. Preliminary characterization checks if the solution truly addresses the business problem, and what's missing beyond the license itself.
Inability to estimate budget and timelines
Without a defined scope, any estimate is a guess. The characterization output allows vendors to provide a responsible estimate, and the client to fairly compare them.
Tensions between departments
Sales, service, and operations see the same process differently. Characterization workshops create a common language and decide in advance where compromises are needed.
The Work Process
Seven Defined Steps
- 01Introduction and stakeholder mapping
- 02As-Is Process Workshops
- 03Mapping existing systems and data
- 04Designing the To-Be process
- 05Initial data model and integration map
- 06Building a Roadmap and estimation
- 07Presenting deliverables to management and obtaining approval
What you get
Actionable deliverables
Requirements document
Clear documentation of business needs, scenarios, users, and constraints.
Process map
As-Is and To-Be diagrams illustrating current and desired workflows.
Solution architecture
Planning of the system, data, permissions, integrations, and core components.
Roadmap
Division into phases, milestones, Quick Wins, and dependencies.
Backlog
Breakdown into Epics, User Stories, and tasks that can be prioritized and implemented.
Estimate and work plan
Assessment of scope, timelines, responsibilities, and risks based on known information.
Success metrics
Pre-defining what will constitute a successful outcome business-wise and operationally.
Decision Point
30-minute initial scoping call
During the call, we will determine if a full scoping, a brief scoping, or a Health Check for an existing system is needed.
When the service is suitable
Typical starting points
- Before purchasing Salesforce.
- Before an implementation project.
- Before expanding an existing system.
- After a project that did not achieve its goals.
- Before Agentforce or AI.
- Before a complex integration.
- When multiple departments need to work within the same system.
- When there is no organizational consensus regarding the desired process.
Decision Considerations
Four decisions that determine the quality of the scoping
Scope of the Specification
A focused specification for one department is sufficient for a Quick Win project. A cross-organizational specification is required when the process spans multiple departments and relies on shared data sources.
Depth of Process Documentation
Not every process requires a BPMN diagram. We invest in in-depth documentation for core processes and lighter documentation for sub-processes.
Success metrics
Define 3–5 business, not just technical, KPIs in advance, so that in a year's time it will be possible to say whether the investment justified itself.
Prioritize Before Perfection
A roadmap that moves the needle within three months is better than a complete plan that only launches a year from now.
Common Mistakes
What is Important to Maintain During the Specification Phase
- Starting a specification without a clear Sponsor from management.
- Documenting the current state instead of defining the desired state.
- Overloading with 'everything we would like' requirements instead of separating Must-haves from Nice-to-haves.
- Skipping the mapping of data sources and data quality.
- Closing a specification without ensuring that actual users have seen the output.
Frequently Asked Questions
Consulting and Specification — Frequently Asked Questions
The Next Step
Initial Specification Call
A brief 30–45 minute call to understand the context and open decisions.