An IT services deal has people on both sides: buyers, presales consultants, architects and delivery leads. HubSpot should show all of them.
Name deal stages after real bid milestones: discovery, solution design, internal review, proposal, SOW review and negotiation.
Label each buyer's role on the deal, so a proposal with no Decision maker on record shows up as a risk.
Treat presales as a cost you track: who joined the bid, when, and how many hours it took.
Watch stage conversion, days in solution design and SOW turnaround to see where architect time turns into signed work.
Procurement emails to ask which SOW is current, and the architect who wrote version three is already on another bid. The answer exists somewhere in your company, just not on the deal record where your sales lead is looking.
HubSpot for IT services has to track a chain of people and documents, not just one owner, one amount and one stage. A default pipeline holds those three fields. In an IT services sale, they hide most of what decides the outcome.
Picture a typical bid. A business sponsor raises the need. An IT leader shapes the requirement, a security team reviews the approach, and procurement negotiates the contract. On your side, the account executive pulls in a solution architect, and a delivery lead checks that the estimate can be staffed.
Each handoff creates a fact the deal needs. Has anyone met the security reviewer? Did delivery sign off on the estimate? Which proposal version is the client reading? Without a place in the CRM, those answers end up in email threads, shared drives and the architect's memory.
What this means for you: take your last three won deals and list every person, on both sides, who touched them. Use the list as your design brief.
Use stages that each mark a milestone where the buyer or your team must do something new. For a project-based IT services sale, that usually means a confirmed need, a scoped solution, an approved internal approach, a priced proposal, an agreed SOW and a signed contract.
HubSpot lets you make chosen properties required when a deal moves into a stage. A deal entering proposal can be required to name a solution architect. A deal entering SOW review can be required to carry a proposal version and a delivery review outcome.
Here's the catch. A required property only confirms that a value has been entered, so "rejected" passes the rule just as "approved" does. Add a workflow that alerts the practice head when a deal reaches SOW review with any outcome other than approved. Then check that outcome in the pipeline meeting and pull back any deal that skipped delivery's sign-off.
The table is a Markivis recommendation, so merge or split stages to fit your offers. Required stage properties, association labels and custom objects depend on your subscription, so check what your portal includes before you design around them.
At a glance: an IT services pipeline for HubSpot, with entry rules and stakeholders for each stage.
|
Stage |
What must be true to enter |
Typical stakeholders |
HubSpot setup |
|
Discovery |
A business sponsor has confirmed a problem and a rough timeline |
Business sponsor, account executive |
Required properties for business problem and target start date |
|
Solution design |
An architect is assigned and requirements are documented |
IT leader, solution architect, presales consultant |
Required solution architect property and a link to the requirements document |
|
Internal solution review |
Delivery has checked the proposed approach and the estimate |
Delivery lead, solution architect, practice head |
Required review outcome and review date, plus a workflow alert when the outcome is not approved |
|
Proposal submitted |
A priced proposal has been sent with a version number |
Business sponsor, procurement, account executive |
Proposal version property and the proposal or quote associated with the deal |
|
SOW review |
The client is reviewing a statement of work with scope and acceptance criteria |
Procurement, legal, IT leader, delivery lead |
SOW version and SOW sent date properties, with the client's legal reviewer associated to the deal |
|
Negotiation |
Scope is agreed and only commercial terms remain open |
Procurement, finance, account executive |
Required decision date and a commercial risk note |
|
Closed won or lost |
A contract is signed, or the loss reason is recorded |
Account executive, delivery lead |
Required close reason and a handoff task to delivery on won deals |
The internal solution review stage records a step inside your company, not the buyer's. Without it, an estimate nobody can staff can reach the client before delivery has seen it.
Questions to ask: Which of our current stages describe our own activity rather than a buyer decision? What would a manager need to see before a deal enters proposal?
Associate every buying-side contact with the deal and add a buyer-role association label, such as Decision maker or security reviewer. The deal record then shows which seats on the buying committee are filled and which are still empty.
We recommend flagging any deal at proposal stage with no Decision maker associated, whatever probability the stage carries. A saved view of open deals with that gap turns the rule into a short weekly list.
Add user properties for the solution architect and the delivery lead, so each deal names the people your company has committed. When one architect appears on four open bids at once, you've found a staffing limit before it costs you a deadline.
What this means for you: for every open deal in solution design or later, check that a Decision maker is on record. Then name the architect and delivery lead on each one.
Put presales effort on the deal record, starting with a bid or no-bid decision at the end of discovery. Record it as a required property with a short reason.
When a deal enters solution design, capture three facts:
Architect assigned: the person scoping the work.
Date joined: when presales time started.
Estimated hours: the expected presales effort, updated with actual hours when the deal closes.
The simplest setup is a task assigned to the presales lead for each new request. A more structured option is a separate ticket pipeline or a custom object for presales requests, which shows the whole queue across all deals.
Proposals and SOWs need version tracking in the CRM, not only in a shared drive. Keep a version number property for each one and update it with every revision you send, with a short note on what changed. When a deal reaches its fourth SOW version, a manager can see the rework without opening a file.
Presales effort is spent long before any revenue is booked, so a deal record that leaves it out understates what each IT services deal costs to win.
What this means for you: add a bid decision, an assigned architect and presales hours to your deal properties this quarter. Make the first two required at the stages where they apply.
Build one dashboard around four views, using the date HubSpot records each time a deal enters a stage:
Solution design to proposal: how much presales work reaches a priced offer.
SOW review to closed won: how often an agreed scope becomes a signed contract.
Days in solution design and SOW review: where deals wait, and whether rework is the cause.
Presales hours on won versus lost deals: what a lost bid costs your architects.
Next to them, count open proposals with no Decision maker on record. Review the dashboard monthly with the sales, presales and delivery leads. Each of them controls a different part of these numbers.
Questions to ask: Which stage holds the most presales hours on deals we later lose? How many open proposals have no Decision maker on record right now?
The facts that decide an IT services deal already sit in architects' estimates, delivery reviews and proposal folders. Stages for solution design, internal review, proposal and SOW give those facts a home on the deal. Required properties make sure each field is filled. Workflow alerts and the pipeline meeting decide whether the answers are good enough to move the deal forward.
Replaying one lost bid is where we begin. With your sales, presales and delivery leads, we walk through it from the first scoping call to the final decision. Along the way we mark every point where information left the CRM for an inbox or a drive. The stages and entry rules come from that walkthrough, and the people who will follow them help write them.
We have no published case study from an IT services company. The closest proof is the HubSpot, CRM and lifecycle work in the Slimstock case study, done for a software company. You can see what else we configure on our HubSpot implementation page.