Nobody trusts the forecast. That is almost never the forecasting tool. It is that a stage means three different things to three teams.

Occasionally, but usually not. When a whole team avoids a tool, the tool is asking for something that does not help them sell. Twenty required fields on an opportunity produces twenty fields filled in defensively, not twenty fields of insight. We watch how deals actually get worked, including the parts happening in notebooks and spreadsheets, then cut the form back to what someone will complete honestly and automate the rest. Adoption follows when the CRM starts giving time back rather than taking it.

Almost never from the forecasting tool. It comes from stage definitions meaning different things to different teams, close dates slipping without anyone recording why, and a number that gets adjusted in a spreadsheet after it leaves the system. Fix the definitions and the evidence required to move a stage, and the forecast starts reconciling. If the number in Salesforce and the number in the board pack differ, that gap is the actual problem and it is worth naming out loud.

That your pipeline data means one thing. An agent answering a question about pipeline reads whatever is in the records, so if a stage means three different things across three teams, the agent will pick one and say it confidently to whoever asked. That was a tolerable internal inconsistency when only humans read it. It stops being tolerable the moment an agent can answer on your behalf. We usually sequence definitions and hygiene first, then agents, and we will say so even when the AI budget is the one that is approved.

Only if your history can support it. Scoring learns from what happened before, so an org where opportunities are created late and closed retrospectively will produce a model that confidently reflects your bad data. If your history is reasonable, scoring is genuinely useful for prioritisation. We will look at the data first and tell you which of the two you have, rather than switching it on and letting the team quietly lose faith in it.

By resisting the urge to build everything. First implementations fail most often from over-configuration: every field someone asked for, every stage anyone could imagine, and a launch nobody can navigate. We start with the smallest process that supports how you actually sell, get it adopted, and add on evidence. It is less impressive in a kickoff deck and considerably more likely to be in use a year later.

Yes, and it starts with reading the org rather than proposing a rebuild. Objects and fields in use versus fields populated, automation firing on the core objects, reports people actually open, and what the sales team does when the system gets in the way. You get that assessment as a document whether or not you continue with us, and it frequently shows that less needs rebuilding than expected.