Every services firm has the same fight. Four systems claim to be the source of truth for the deal, and none of them can carry the whole thing. The CRM holds the headline. The spreadsheet holds the detail. The project tool holds the work. Finance holds the recognition. They are all right, in their own scope, and all wrong outside it.
The fight gets dressed up as a tooling problem. It isn't. Rolling out a new CRM, a tighter estimation template, or a "single platform" for the lifecycle does not resolve it, because the underlying issue is a missing assignment, not a missing tool. The deal is not one fact. It is at least four, with different owners, and most firms have never decided who owns each.
The unowned fact is the expensive one. Commercial viability, the structured link between scope, price, schedule, capacity, and margin, has no natural home in the four systems above. So it gets reconstructed in someone's head every time it matters. At the negotiation. At the redraft. At the change request. At the post-mortem. Differently every time. That is the cost most firms write off as "fragmentation".
Four facts, four owners
Treat the deal as four facts. Assign each to the system actually built to carry it. Make the handoffs between facts cheap. Leave nothing unowned.
CRM owns the opportunity
The CRM is responsible for: who the customer is, what stage the deal is at, who owns it, and a single headline number. That is the right scope for a CRM. Every other tool will refer to it when they need to ask "is this real?".
CRMs break when teams force commercial detail into them. Custom objects modelling roles, rates, milestones, and effort look tidy in a Salesforce admin demo and fall apart the first time a deal needs to be repriced from scratch. Workflow rules end up enforcing the wrong invariants. Reports get unreliable. The team that wrote the schema leaves and no one else dares touch it.
What "good" looks like: the CRM holds the opportunity record, the headline value, and a link to whichever system holds the structured commercial detail. Nothing more.
In firms with a bid-proposal practice, qualification splits off as its own fact: response patterns, win/loss history, go or no-go calls on whether the deal is worth pricing. That fact lives with the practice, sometimes in a dedicated bid-proposal tool, and feeds back into the opportunity as a gate before any of the work below begins. It does not replace the facts that follow. It just means the first decision is not "what shape is this deal" but "are we pricing it at all".
The spreadsheet carries the detail, badly
In most firms, the structured commercial detail lives in a spreadsheet. Roles. Rates. Effort assumptions. A schedule. A margin calculation. The detail is real and the spreadsheet, on a good day, carries it.
What it cannot do: be queried across deals, version itself reliably, or hand its contents to another system in a shape another system can read. Every cross-deal comparison becomes a manual exercise in opening twelve files. Every change request becomes a fork. Every audit becomes a forensic exercise.
Spreadsheets are not the problem because the calculations are wrong. They are the problem because the detail cannot leave them.
Delivery tools own delivery state, not commitment
Jira, Asana, ClickUp, Monday. Pick your poison. They own the delivery state of the work: tasks, assignments, status, time spent. They are not built to carry the commitment that started the work. The commercial shape of the deal (what was sold, at what price, on what schedule) gets re-entered manually after kickoff, in whatever structure the delivery team likes that quarter.
The handover failure here is well known. Sales sells one shape. Delivery rebuilds it in the project tool with a different shape. The two never reconcile. Margin variance has nowhere to land because no field in the project tool carries the commitment to compare against.
A clean handoff pushes the structured commercial scope into the delivery tool at kickoff, with stable identifiers, so actuals can be compared back to commitments without a tagging exercise after the fact.
Finance owns recognition, downstream of everything
Finance owns revenue recognition, billing, and the closed-out P&L. Recognition rules need a structure: what was committed, on what milestones, with what dependencies. Without a feed of that structure, finance reconstructs it from invoices and PM updates, which is slow and lossy.
The right input to finance is a feed of the milestone schedule and the structured commitment, generated upstream and delivered as data, not PDFs. Most firms send finance a contract and ask them to figure it out. That is finance bearing the cost of an unowned fact.
Where commercial viability actually lives
The unassigned fact is commercial viability. It is the calculation that decides whether the deal is sellable, deliverable, and profitable, all at once. It links scope to price, price to schedule, schedule to capacity, and capacity to margin. Without an owner, every cross-team conversation about a deal starts with a reconciliation of four numbers that should be one.
The system that owns it has to do five things. Model scope, roles, rates, effort, schedule, milestones, and margin in one structure. Version itself, so what was committed is recoverable. Generate the customer-facing artefacts (proposal, SOW, spreadsheet) from the same model. Push the commitment downstream to delivery and finance with enough structure that actuals can be reconciled back against it. Stay out of the systems that already own opportunity, delivery, and recognition, while feeding each one what it needs to do its job.
That is a different job from the CRM, the spreadsheet, the project tool, and the finance system. None of them want it. None of them are built for it.
In practice
This is the slot Estii is built for. The structured commercial object covers scope, schedule, payment milestones, and rate cards in a single model. Generated proposals and spreadsheet exports render from it without re-keying. Deal versions snapshot every redraft and approval, so what was committed in March is one click away in November.
Downstream, integrations push scope, schedule, and rates into Jira and ClickUp at handover with the structure intact: tagged tickets that carry the priced scope, schedule rows that match the commitment, identifiers that survive the handover. Spreadsheet exports carry the same WBS for finance to reconcile against. None of this turns Estii into the CRM, the project tool, or the finance system. It gives each of them a cleaner version of the fact they already own, and leaves a structured trail so actuals can be measured back against the original commitment when the project closes out.
The point is not the tool. The point is that commercial viability has to be owned by some system. If your firm has not assigned it, the spreadsheet has it by default, and the spreadsheet cannot hand it to anyone else.
One fact, one home
When commercial viability has an owner, the other handoffs get easy. The CRM stops trying to model effort. The spreadsheet stops being the integration layer. The delivery tool stops being told what was sold over a Slack thread. Finance stops chasing invoices to figure out recognition.
When it has no owner, every cross-team conversation about a deal opens with a reconciliation. A practice lead opens the spreadsheet. The seller opens the CRM. The PM opens Jira. The CFO opens NetSuite. Half the meeting is comparing four numbers that should be one.
The fight is not about which tool is best. It is about which fact each one owns, and whether the most important fact has anyone at all.
