Commercial events
What turns an account, lead, order, contract, service request or commitment into something the business needs to act on.
Business analysis and requirements discovery before CRM, ERP, automation and software implementation.
A stakeholder can accurately say, “we need an approval workflow”, “we need another pipeline” or “we need an alert”. That is evidence about what someone currently believes the system should do.
Commercial Discovery goes one level earlier: what event creates the need, what decision is being made, what information is available, what happens when the normal case breaks, and what outcome the organisation is trying to protect.
Only then does it become a system requirement.
The boundary follows the implementation initiative. This is not a general audit of the client company.
What turns an account, lead, order, contract, service request or commitment into something the business needs to act on.
Who decides, what they need to know, where responsibility moves and what happens when ownership is unclear.
Non-standard terms, customer-specific commitments and the cases that make an apparently simple workflow expensive.
What must be known at each point, where it currently exists and what management needs to see.
Whether terms such as customer, opportunity, active, complete, renewal or qualified mean the same thing across functions.
What is recorded, repeatedly observed, independently described, inferred or still assumed - and where measurement needs to be created rather than presumed to exist.
The output is written for implementation, not for theatre. It separates recorded facts, stakeholder accounts, observed patterns, inference, assumptions and unresolved decisions so that your architect does not have to reverse-engineer the business logic from meeting notes.
I stop at the agreed boundary. Your firm owns platform selection, solution architecture, implementation and commercial terms.
The analysis method stays the same. The visible relationship can stay entirely with your firm.
You supply transcripts, notes and source material. I analyse and structure the output.
Your account lead stays visible; I join selected stakeholder conversations where deeper elicitation is useful.
I work under the agreed partner process and brand, with no independent solicitation of the end client.
Not as part of Commercial Discovery unless platform comparison is explicitly in scope. The core job is to establish what the business needs the solution to represent.
Yes. Existing requirements are useful evidence. I trace them back to business events, decisions and outcomes, flag contradictions and identify where a requirement is still an assumption.
That depends on the engagement. I can work openly, as part of your team, or behind the scenes. Any disclosure required by contract, privacy or data-protection obligations takes priority over branding preferences.
No. I deliberately stop before implementation. That keeps the discovery independent of a particular technical answer.
Commercial Discovery is the method. Business analysis is the market language. If you need extra BA capacity before solution design, start here.
Business analysis for implementation partners →Send me the implementation type, what the client says it needs, and what still feels unclear.