CRM data degrades because the system was built for reporting, not for selling
Required fields exist because a report needs them, so they are completed at the last moment with minimal thought, and the forecast is built on that.
In a services firm, pipeline is a resource demand forecast. Treating it only as a revenue forecast is why delivery cannot meet the dates sales commits to.
Ask a services firm how its forecast is produced and you will often hear a description of a meeting. Somebody presents, others push back, a number is agreed. It is a reasonable process among experienced people and it is not a forecast, which is why nobody can explain the variance afterwards.
This paper argues that the more consequential failure is not forecast accuracy but the absence of a capacity forecast. Pipeline in a services business is a resource demand signal, and firms that instrument it as one consistently report more measurable value than those that pursue forecast accuracy alone.
If you read nothing else, read these. The analysis that follows sets out the evidence for each.
Required fields exist because a report needs them, so they are completed at the last moment with minimal thought, and the forecast is built on that.
Which is why, in most firms, nobody explains it. The meeting becomes necessary because the data is poor, which further reduces the incentive to maintain the data.
An opportunity that records the roles and dates it will require lets resourcing plan against probable work. This change typically produces more value than the forecast improvement accompanying it.
If pipeline reviews are run from a spreadsheet, sellers correctly conclude the CRM does not matter. We train managers before sellers for this reason.
The system was configured to satisfy management reporting rather than to help the person selling. Nineteen mandatory fields exist because nineteen report columns exist. They get filled in at the last possible moment with the least possible thought.
Once the data is known to be poor, the pipeline meeting becomes necessary to correct it. That meeting produces a number, and the number's existence reduces the incentive to maintain the underlying data further. It is a stable equilibrium and an expensive one.
Breaking it requires making the system useful to the person entering the data, which in practice means three things: activity captured automatically rather than typed, mandatory fields justified individually, and a sales process configured around how the firm genuinely sells including where practices differ.
An opportunity carries a value and a probability. In a services firm it also implies a demand: two consultants of a particular skill, starting in a particular month, for a particular duration.
Capturing that at the opportunity stage — lightly, at the level sales will actually complete — converts pipeline into a demand curve that resourcing can plan against. Weighted by probability and aggregated by role and month, it lets a firm soft-book against probable work rather than waiting for signature.
The obstacle is rarely technical. It is that sales and resourcing report to different people, meet separately, and have no shared artefact. The weekly conversation is the mechanism; the tooling only makes it possible.
Microsoft's current direction for Dynamics 365 Sales is agentic: research conducted across CRM and external sources, records enriched automatically, next actions recommended rather than requested.
This raises rather than lowers the value of basic data discipline. An agent reasoning over a pipeline of placeholder values will produce confident recommendations built on nothing, and it will do so faster and more persuasively than a human analyst would.
The firms that benefit will be the ones whose data was already worth reasoning over. That is an argument for fixing capture now rather than waiting for the capability to arrive.
Every paper in this series ends with a framework you can run internally. We would rather you used it and reached your own conclusion than took ours on trust.
Five steps. The first two are usually skipped and the last is where the value lands.
Justify every mandatory field individually. We routinely take firms from nineteen to six.
Activity from Outlook and Teams automatically, so recording is not retyping.
Add role, effort and expected start to the opportunity — lightly, at a level sales will complete.
Derive stage probabilities from historic conversion, not from seller confidence.
A weekly sales and resourcing conversation from one view. Without this, nothing changes.
The same argument lands differently across an executive team. These are the three versions worth separating.
Microsoft's own documentation for the product behaviour described above. We would rather you verified the basis than accepted our summary of it.
On these references: each entry names a Microsoft Learn article or documentation area by title, because deep links change while titles are stable. Searching the title on learn.microsoft.com will reach the current version. Where we have cited a figure or a product behaviour, it is Microsoft's statement rather than ours; where we have given a number of our own it is labelled as such in the text.
Describe how a deal actually moves through your firm and we will configure a demo around that process, then put it in front of the sellers and the resourcing lead together.
Before evaluating any system, do this calculation. It usually settles the investment question faster than a vendor business case.
Professional services firms are increasingly losing time at procurement rather than at pitch, and the reason is a document nobody owns internally.
Describe the situation in your own words.