Salesforce Isn't a PreSales Platform — and It Was Never Designed to Be One

This is not a criticism of Salesforce. It is a very good CRM, and a CRM is a system of record for the commercial shape of a deal. The technical evaluation is a different kind of object, and no amount of custom-field configuration turns one into the other.

Written by WinIQ. We build one of the products described here, so read the comparisons with that in mind — we have tried to describe every category by what it is designed to do rather than by what it lacks.

What a CRM is designed to model

An opportunity: stage, value, close date, contacts, forecast category. Everything in the data model exists to answer a commercial question — how much, from whom, by when. That is a genuinely hard problem and CRMs solve it well.

What the technical evaluation produces instead

Requirements, individually, with your assessment against each and the evidence behind it.
Architecture constraints — the existing estate, the integration surface, what will not work in this environment.
Objections raised and answered, and whether the answer worked.
What a POC actually proved, as distinct from whether it passed.
Technical disposition — why the evaluation went the way it did, in a form that survives the engineer moving teams.

None of these are opportunity attributes. They are many-to-many, deal-shaped and reusable across deals — a requirement answered for one customer is worth having for the next twenty.

Why custom fields do not close the gap

The usual response is to add fields to the opportunity object. It fails predictably: the fields are a filing task with no reader, so they are filled in late, filled in thinly, or not at all. A field nobody consumes is dead weight and everybody on the team learns to skip it within a quarter.

The test

Pick a requirement your team answered six months ago in a deal you won. Can anyone retrieve the answer, the source behind it and who approved it, in under five minutes? If the answer is “ask a person”, the system of record for technical work is that person.

What to do instead

Keep the CRM as the commercial system of record — it is good at that and replacing it is a bad idea. Add a layer beside it for the technical evaluation, joined on the deal identifier so the two can be read together without either owning the other. The integration that matters is boring on purpose.

The one rule that decides whether such a layer survives: it has to capture from the work itself — the RFP being analysed, the questionnaire being answered — rather than asking anyone to file. Every previous attempt at this failed on exactly that point.

Frequently asked

Can Salesforce be configured for technical sales work?

Partly. You can add objects and fields to hold requirements or POC records, and some teams do. The limitation is not technical capacity, it is that the data has to be entered by hand as a separate task from the work, which is why those fields are empty within a quarter. The CRM remains the right system of record for the commercial side of the deal.

Does a presales layer replace the CRM?

No. It sits beside it, joined on the deal identifier. The CRM stays the system of record for stage, value and forecast; the presales layer holds requirements, evidence, objections and technical outcome.

What about Salesforce's own AI features?

They operate on CRM data — activity, pipeline, correspondence. The technical evaluation's raw material is documents and requirements, which mostly do not live in the CRM at all.