A sales pipeline shows the status of sales opportunities and the work needed to move them forward. In a services company, its value lies in making visible what has already been confirmed: need, scope, decision, and start conditions. If the stages depend solely on each salesperson's optimism, the board is no longer reliable.
Designing a useful pipeline requires agreeing on when an opportunity enters, what evidence allows it to move forward, and how it ends. The following model serves as a starting point for firms, agencies, consultancies, and other service businesses. Adapt it to your operations and keep only the stages that represent different decisions.
First define what deserves to enter the pipeline
A general inquiry may be in your contact database without yet being an opportunity. To enter the pipeline, it is useful to identify a need your business can address and a person with whom to explore it. This prevents filling the stages with names lacking a project or context.
Also define what each record represents. A company may hire an implementation and later a maintenance service. If the scopes and decisions are different, they may require separate opportunities. Maintain a clear link to the same customer so you do not lose sight of the relationship.
Stage 1: need to be confirmed
Record the initial problem and validate whether there is a fit with your services. Ask what the customer wants to achieve, in what context, and why they are considering it now. The goal is to decide whether it is worth continuing the conversation and what information is missing.
The exit criterion may be a confirmed need, viable coverage, and an agreed meeting or exchange to define the scope. If you cannot handle the case, close it with a clear reason. Keeping it open to make the list appear larger does not help you sell.
Stage 2: diagnosis and scope
Here you clarify deliverables, constraints, people involved, and possible timelines. In services, two projects with the same name may require very different efforts. Training for a small team and an implementation for multiple branches require different assessments.
Move forward when you have enough information to propose a responsible solution. Document assumptions and pending items. If operations must confirm capacity or a technical dependency remains unresolved, make that condition visible instead of hiding it within an estimated date.
Stage 3: solution presented
The proposal should correspond to the diagnosis: scope, responsibilities, conditions, and start process. The stage indicates that the customer received a concrete solution to review. Sending a file without confirming that it addresses the need does not, by itself, demonstrate sales progress.
To leave this stage, look for a verifiable signal: the customer confirmed the review, identified adjustments, or explained their decision-making process. Record who is involved and what information they request. The next task should respond to that situation, without turning the pipeline into a calendar of repeated messages.
Stage 4: decision and conditions
At this stage, pending conditions are resolved so both parties can make a decision. There may be scope adjustments, coordination with purchasing, or an availability review. Distinguish active negotiation from an opportunity where no one has confirmed recent interest.
Define what evidence you need to mark an opportunity as won. Depending on your sales model, it may be formal acceptance, a signed contract, or fulfillment of a contracting condition. Agree on the criterion with administration and operations to prevent each area from using a different definition.
Stage 5: close and handoff to the responsible team
Use clear outcomes: won, lost, or postponed. A postponed opportunity needs a reason and a review condition; otherwise it may remain open indefinitely. For lost opportunities, record what you know without attributing causes the customer did not confirm.
When you win, hand over the accepted scope, commitments, and contact people to the operations team. The sales pipeline ends according to your contracting criterion, while execution continues in its own process. Separating these moments makes it possible to identify responsibilities without confusing a sale with a delivered service or collected money.
Support each stage with minimum rules
A list of stage names still leaves many decisions open. Define the following elements in a brief guide that everyone can consult:
- Evidencia de entrada: qué debe saberse para ubicar ahí una oportunidad.
- Criterio de salida: qué hecho permite avanzar o cerrar el caso.
- Responsable: quién coordina el próximo paso.
- Fecha de revisión: cuándo comprobar si hubo un cambio.
- Motivo de bloqueo: qué impide continuar y de quién depende resolverlo.
Start without invented close percentages. If you later want to estimate results, use data from your own process and distinguish an estimate from guaranteed revenue. An advanced stage can still end in a lost sale.
Review exceptions and stalled opportunities
A weekly review can focus on decisions: what moved, what is blocked, and what support is needed. Avoid asking each person to narrate all their activities. Observe how long cases remain in each stage and whether the close date has a known reason.
When a project changes scope, review its position in the process. Moving back a stage may better reflect reality than preserving the appearance of progress. What matters is that the pipeline describes what you know today.
Use a tool that supports your method
Onix Board provides contact, ticket, and team activity management. Request a demo at onixboard.com to review how it can support your sales organization and what configuration you would need. Bring your stages and criteria: this way you can assess the fit with your process before adopting a way of working.