Future-state process scope by input and outcome
Key Takeaway
Define a future-state process by the input that starts it and the outcome it delivers, not by the application where the work happens. When you drill into an activity box, that box's own input and outcome set the scope of the more detailed map.
Scoping a future-state process by input and outcome means defining it by what starts it and what it delivers, not by the application where the work happens. The input and outcome the team agrees on set the boundary for the whole process map and for every lower level of detail. Scoping this way keeps the design focused on a better business outcome rather than a better set of screens.
Why scope by input and outcome
When you design a future-state process, define it by its input, the thing that starts it, and its outcome, the result it delivers. Don't define it by the application the work happens in.
Business processes aren't just about Salesforce. Many applications and manual activities drive day-to-day work, so Salesforce screens don't always cover the whole process.
You're designing a better business outcome, not just a better application, so always consider the broader end-to-end process, even when Salesforce handles only part of it.
A home insurer wants to redesign how it handles storm damage claims. A policyholder phones to report the damage. A claims handler logs the claim in Salesforce. Next, an adjuster visits the house and writes notes on paper. Finally, a separate payment system sends the money. If the team scoped the process as the claim screens in Salesforce, the site visit and the payment would fall out of the design. Instead, the team scopes the process from a policyholder reporting storm damage to the claim payment reaching the policyholder. Every step in between is now in scope, whichever application or person handles it.