Why process comes before the build
Security decides who can see what. Data decides whether what they see is true. Process decides whether the system reflects how the business actually runs. Until all three are settled, anything built on top of them inherits the gaps.
Process, for us, is not an operating model exercise. It is the far less glamorous work of understanding the daily tasks people actually perform, and translating those into a system that supports them rather than fighting them.
Salesforce will faithfully reproduce whatever it is given, including the parts that do not work. So we take the time to understand how your business operates and translate this faithfully into systems that can be described and then automated.
Where process sits in the sequence
Process is pillar three because automation built on an undefined process automates the wrong thing, reliably.
Establish before you expand
Security, data, and process are the foundation of any business system. Everything that you build on top of this inherits their rigour, or their faults. That’s why they are always our starting point for any work we do.
Process is the third foundation and the one most often skipped, because it is the only one that cannot be bought. It has to be worked out with the people who do the job.
How we think about process work
Worth being precise, because process work means very different things to different firms and we prefer to be clear about where we are useful.
- Sitting with the people doing the work and recording what actually happens
- Agreeing who owns each step, who approves, and what finished means
- Working out which exceptions are real and which are habit
- Getting to something specific enough to configure Salesforce from
- Keeping it tied to a system you are actually going to build
- Reviewing your operating model, or proposing a restructure
- Benchmarking you against an industry framework
- Producing two hundred pages nobody opens twice
- Treating process improvement as an end in itself
- Competing with management consultancies on their ground
The tools we work with
Four of them. How far we take each depends on the size of the estate and how many teams the process crosses.
We use these because they force decisions rather than record opinions. The ownership matrix in particular tends to settle arguments that have been running for years.
A document earns its place by changing what gets configured.
Where to begin
Whichever of these sounds most like you.
A conversation about how the work actually runs, before anyone scopes a build.
Salesforce consultancyPut approvals, routing and case triage into Flow so the process runs the same way every time.
Business process automationA review of what you have, what has been superseded, and what to do first.
Salesforce health checkStart with how the work happens
Process is the foundation nobody can sell you off the shelf, because it has to be worked out with the people doing the job. That is also why it is the one that makes everything after it possible.
Automation, an integration programme or an AI pilot all rest on an agreed process underneath. That agreement is worth an hour before it is worth a budget. Get in touch and we can give you a clear view of where things stand.
Salesforce process design: frequently asked questions
In part, but the scope is deliberately narrower. We map the processes you intend to run in Salesforce, to the level of detail needed to configure it. We are not reviewing your operating model or benchmarking you against a framework, and we do not compete with management consultancies on that ground.
A single process is usually days rather than weeks. A connected set, for example everything from enquiry to invoice, takes longer because the interesting part is the handovers between them. We scope it once we know how many processes and how many teams touch them.
Usually yes, and the documentation is a good starting point. The value is in the difference between what is written down and what happens, and that difference is where the cost sits. Where they match, the exercise is short and you have proved something useful.
Not every one. A small, well understood change does not need it. It matters most when you are implementing for the first time, replacing something, automating a process that spans teams, or building anything an AI agent will later act on.
That is the normal outcome, and it is better to surface it in a room with us than in user testing after the build. Part of the job is getting a decision made and recorded rather than leaving two versions running.
No. Occasionally the honest answer is that the process needs fixing before any system will help, and once in a while that defining it properly removes the need to build anything at all.