Pipeline Design
Part of Choosing CRM software for a sales team
Defining CRM requirements from the sales process
Turn a real sales process into checkable CRM requirements using events, roles, information needs, exceptions and acceptance results.
Define CRM requirements by tracing what happens to a sale, who acts at each point and what information the next person needs. Write each requirement as a result someone can check. “Better pipeline visibility” is vague; “the manager can find open opportunities with no named next action” gives the team something to assess.
Follow the work from enquiry to decision
Talk to the people who receive enquiries, sell, approve terms and take over won work. Use a recent ordinary sale and an awkward case. Note where information enters, when ownership changes, what counts as progress and where a customer commitment can be lost.
Separate the current method from the outcome needed. Copying details between two lists may describe today's habit without being a requirement for the new system. A small table can capture the work:
| Event | Person who must act | Information they need | Result to check |
|---|---|---|---|
| Enquiry accepted | Assigned representative | Customer question and contact route | A response has an owner and due date |
| Opportunity changes owner | Incoming representative | Current position and open commitment | They can continue without reconstructing the history |
| Sale agreed | Receiving team | Approved scope and responsible contact | They can accept the request or return it for clarification |
These rows are illustrative, not default CRM stages. Use examples that reflect your own sales process.
Write checkable requirements
Use a simple form: when [event], [role] can [action], so [result] is visible. Include an exception when it changes the work.
For example: “When a current customer sends a new enquiry, the representative can record it without losing the existing customer context; an uncertain match goes for review.” This states the outcome without prescribing a button or automation.
For each requirement, note who owns the business decision, which records are involved and what would show that the result works. Challenge broad requests such as “capture every email”. The underlying need may be for colleagues to find the agreed scope and latest commitment while keeping unrelated messages out of view.
CRM Feature Comparison: Key Platforms for Australian Sales Teams
- Microsoft Dynamics 365Supports custom business process flows; integrates with ATO and GST systems.
- HubSpot CRMEnables pipeline setup with drag-and-drop stages; ideal for small to mid-sized Australian businesses.
- Zoho CRMOffers blueprint-based process design; suitable for teams needing workflow automation.
- PipedriveProvides flexible plans with built-in sales activity tracking; good for field sales teams.
Separate essential work from preferences
Mark a requirement essential for launch if the agreed sales process cannot run without it. Mark it later if a manual step is acceptable for now. Remove preferences without a clear user or decision. Ask what would happen if each proposed field, notification or report were absent.
Do not make every process step a mandatory field. Decide what must be known at that point and who can provide it. Some CRM products can require information at a stage, but the control and edition vary. State the needed outcome first; decide how to implement it after choosing a product.
Finish with acceptance criteria
Give each essential requirement a representative case and an expected result. Include an ordinary sale and the exceptions that matter, such as an existing customer with a new opportunity, missing information or a change of owner. Record what the intended user must be able to see or do, and who will decide whether the result is acceptable.
The finished list should be short enough to guide a buying decision and precise enough to check during implementation. It should describe what the sales process needs to achieve while leaving room for different products to deliver it.
