Using Salesforce for Competitor Analysis

Almost every article about competitor tracking in this system opens by explaining how to create a custom field, which quietly implies there was nothing there before. There was. The data model has carried a dedicated competitor object for longer than most of the orgs reading this have existed, and in a great many of them it is invisible, because a related list has to be placed on a page layout before anybody can see it.

What you are really dealing with, then, is a product carrying two competitive layers, only one of which most teams know about. The first is a purpose-built object holding several rivals per opportunity and a long text field of context for each. The second is whatever custom fields your admin added, which is what Salesforce’s own training material recommends and what nearly every implementation actually runs on. Both work. They answer different questions, they are reported on differently, and running both at once is the one combination that reliably produces two numbers and an argument.

Underneath either layer sits the part nobody has to maintain: stage history, activity, amounts and close dates, accumulating whether or not anybody has thought about competitors this year. That layer is trustworthy in a way the competitive fields never are, and it is where an investigation should start when the competitive fields turn out to be empty.

1. 1Look for the Competitors related list before assuming it is missing. Open an opportunity and check the page layout. Salesforce's object reference documents a standard object representing a competitor on an opportunity, but the related list has to be placed on the layout before anyone can see it. In a great many orgs the data model contains the feature and the interface does not, which is why teams conclude the product has no competitor tracking at all.
2. 2Read what the standard name field actually is. The object's competitor name is documented as a combobox, and Salesforce defines a combobox as a picklist that also lets users type a value not already in the list. So the field that looks like a controlled list is not one. Knowing this before you standardise on it is the difference between a countable dataset and three spellings of the same company.
3. 3Decide between the standard object and a custom picklist, once. The object holds several rivals per deal and two long text fields of context; a restricted picklist on the opportunity holds one name that every report can group by without ambiguity. Salesforce's own competitor training builds the picklist. Running both is the only genuinely bad answer, because two half-populated fields produce two different numbers and an argument about which is right.
4. 4Add a separate lost reason list, and keep the two apart. One field names who won, the other gives the stated cause. Mixing competitor names into a reasons list means you can count neither, since some competitive losses were filed as price and some price losses were filed as a company name. Salesforce's module treats them as two fields for exactly this reason.
5. 5Enforce it with a validation rule at the closing stages. Salesforce's competitor module requires its competitor field once an opportunity reaches proposal, negotiation or either closed stage, and requires the lost reason on closed lost specifically. That placement is the point: required at creation captures a guess about a shortlist nobody has settled, required at close captures an answer.
6. 6Backfill four quarters from the activity record. Notes, tasks, emails and logged calls name the rival on most significant deals even where no field existed. Work backwards through closed opportunities above a value threshold, populate the new field, and flag those records so the reconstruction is never mistaken for something recorded at the time.
7. 7Build the three reports Salesforce's own module specifies. Opportunities grouped by competitor and stage, filtered to the closed outcomes. Lost reasons grouped by competitor, filtered to closed lost. And win or loss rates by competitor using formula columns. Put all three on one dashboard so nobody rebuilds them differently each quarter, which is the failure mode that ends most competitive reporting.
8. 8Read the Strengths and Weaknesses text before quoting any percentage. If the standard object is populated, you are holding a dated corpus of what sellers understood about each rival, deal by deal. Read a quarter of it end to end once. The recurring sentences are the rival's real pitch, and they will change what your team says in a way no win rate ever has.

Salesforce’s object reference describes OpportunityCompetitor plainly: it represents a competitor on an opportunity, and its documented purpose is managing competitors on an opportunity, associating several with one deal and specifying the strengths and weaknesses of each. The field list is short. A competitor name, a required link to the opportunity, and two text fields capped at a thousand characters each, one for strengths and one for weaknesses.

Read that list again and notice what it makes possible. Several rivals on one deal, each with its own written assessment, all queryable. Very few CRMs offer that shape at all. Now notice what decides whether it works.

The one detail that explains the messy data

The competitor name is typed as a combobox, and Salesforce defines a combobox in the same document as a picklist that also allows users to type a value that is not already specified in the list. A field that presents as a controlled list therefore accepts anything at all. That single design detail is the whole reason competitor reporting in orgs using this object tends to collapse: the same company arrives as three spellings, each one is its own group in a report, and the totals look plausible while being wrong.

Salesforce’s own competitor tracking module makes the same argument about plain text, using the example of one rep entering Acme, another Acme Inc and a third Acme Industries, and describes the result as messy and inconsistent competitor data. It then tells the admin to build a restricted picklist on the opportunity, plus a separate lost reason list. That is the vendor routing around its own feature, and it is the clearest guidance available on which layer to standardise on.

Choosing between them, with the trade written down

For most teams the picklist is the right answer and the object is a bonus where it happens to be populated. For a team running long, formally evaluated deals against a stable set of rivals, the object earns its keep on its own, provided somebody normalises the names quarterly. A CRM built so the competitor is a first-class record rather than a child row removes the normalising problem altogether, which is the comparison worth having before you invest in either, and Attio is the clearest example of it.

Two thousand characters per rival per deal, written by somebody who spoke to a buyer who was evaluating both of you. Across two years of contested deals that is not a field, it is a longitudinal, dated corpus of how a competitor argued against you and how those arguments changed. It is also, in most orgs that have the object enabled, almost entirely unread.

The reason it goes unread is that it cannot be counted, so it never reaches a dashboard, so nobody opens it. That is a reporting habit rather than a property of the data. Read as text it outperforms every percentage on this page, because a win rate tells you that something is happening and a sentence tells you what to say on Thursday.

What to write in each field, and what not to

Strengths records what the buyer said the rival was better at, in the buyer’s own framing, not the seller’s translation of it. Weaknesses records what the buyer said the rival could not do, along with who told them so, because a weakness the buyer discovered themselves and one your own seller planted are different pieces of evidence with the same shape. Neither field is the place for an opinion of the competitor, and the reason is practical as much as legal: an opinion is unfalsifiable a year later, whereas a quoted objection can be checked against the rival’s current documentation in five minutes.

Reading a quarter of it in one sitting

Export the competitor rows for one quarter, sort by rival, and read every entry for the two rivals that appear most. It takes about an hour and produces three things a report cannot. The recurring sentence, which is the rival’s actual pitch as buyers repeat it. The claim that appears in won deals but not lost ones, which is the objection your team already answers well. And the claim that appears only in losses, which is the one nobody has an answer for and is the single most useful output of the whole exercise.

The retrieval problem, and the fix

Long text fields are not searchable in the way people expect, which is why this corpus tends to stay locked inside the org. The workable fix is small: run one report per quarter of competitor rows with the two text fields as columns, export it, and keep the files. Two years of those exports is a searchable archive in a folder, and it survives the org being reconfigured, the object being deprecated in your instance, or the person who cared about it leaving.

Eight rows, graded above. Taken one group at a time, sorted by whether a person had to decide to record it, since that is what bounds how far any of it can be trusted.

The competitive layer, whichever version you run

The OpportunityCompetitor object holds several rivals per deal and is queryable through the API, which makes it the only route to an honest picture of a three-way evaluation. The strengths and weaknesses fields are the subject of the section above and the reason the object is worth keeping even where the picklist does the counting. A custom competitor picklist is what every grouped report will actually run on, so hold its values to a short restricted set that also takes in the endings where no vendor won at all: no decision, an in-house build, other. A custom lost reason picklist records the stated cause and must stay a separate field, or neither question can be counted. The general wider method for producing figures from any of it lives under CRM data.

The rule that decides whether any of it exists

Stage-based validation rules are not an implementation detail, they are the difference between a dataset and an empty column. Salesforce’s own module requires the competitor field once an opportunity reaches proposal or price quote, negotiation or review, closed won or closed lost, and requires the lost reason on closed lost specifically. That placement is deliberate and it is worth copying exactly: earlier in the pipeline the honest answer is that nobody knows yet, and a required field asked before its answer exists simply trains everybody to click whichever value clears the dialogue fastest.

The half nobody has to remember

Opportunity stage and field history is written by the platform, so it carries none of the reporting bias the competitive fields do. Total cycle length is the headline; the stage that stretches is the finding, since an evaluation phase that doubles whenever one rival is present marks the exact point their comparison bites. Field history has to be switched on per field, so check what is being tracked before planning anything that depends on it, and switch tracking on for the competitor field the day you create it rather than the day you need its history.

Where the rival is named on every old deal

Opportunity notes, tasks and activity carry the competitor’s name on most significant deals that closed before anybody built a field, which makes them the raw material for a backfill rather than an ongoing source. They also hold what no structured field will: when the rival appeared, what they offered, and the buyer’s own wording. Reports grouped by competitor are the output layer, and Salesforce’s module specifies the three worth building before you invent your own.

Reporting here is strong enough that the temptation is to stop inside the org, and for the standing numbers that is the right call. Everything else wants to leave, for one reason: a competitive analysis nearly always needs to be joined to something the org does not hold, and a report cannot join to a rival’s published price list or to notes from a buyer interview.

Build the three reports first, and put them on one dashboard

Salesforce’s competitor module specifies opportunities grouped by competitor and stage filtered to closed outcomes, lost reasons grouped by competitor filtered to closed lost, and win or loss rates by competitor with formula columns computing the percentages, assembled into a single competitive analysis dashboard. Copy that, and copy the dashboard part in particular. A number that lives in one agreed place gets rebuilt the same way each quarter; a number somebody recreates on demand gets rebuilt differently and starts an argument about which version is right.

Formatted or details only, and why it matters

Exporting a report offers two views and they serve different jobs. The formatted export reproduces the report as it appears, groupings and filter header included, so it reads the way the dashboard reads and files well. The details only export drops the presentation and returns one row per record, which is the one to take for analysis, because rows can be pivoted, filtered and joined afterwards and a rendered grouping cannot. Take details only, keep the competitor, stage, close date, amount and outcome columns, and record the filters you used in the filename.

The sheet worth keeping outside the org

One row per closed opportunity, with the rival named, the outcome, the amount, the cycle length and the stated reason. Add a column for the quarter it was exported in and keep every file. Two years of quarterly exports is a competitive history that no org reconfiguration can take away from you, and it is what makes a year-on-year comparison reproducible. The win/loss report template gives that sheet a shape somebody outside the sales team will actually read.

The evidence an org cannot generate

Nothing above tells you what the rival did, because no object in the org observes anything outside your own pipeline. Teams that want that half kept up to date rather than reconstructed each quarter run a competitive intelligence platform against the CRM, which files what a rival published beside the opportunities where it matters. Worth being clear about the limit: it makes no difference whatsoever to how well your Strengths and Weaknesses fields are filled in, and those remain the most valuable thing in this system.

Check the layout before you check anything else

The standard object stays invisible until its related list is placed on the opportunity layout, and it has to be there on every record type you care about, since a layout carrying it for new business will not necessarily carry it for renewals. This is worth ten minutes at the start because it determines the entire shape of the project: an org where the list is present may already have years of populated competitor records nobody has read, and an org where it is absent is starting from zero regardless of what the data model contains.

What you need to be given

For the analysis, a read-only reporting role over closed opportunities and the ability to build and save reports in a shared folder. That is a much easier request to approve than broad record access, and it leaves live deals untouched, which is the thing sales leadership is usually protecting when it objects. For the setup, an admin has to create the fields, the validation rule and the field history tracking. Agree who owns the picklist values before anything is built, because a competitive set that requires a ticket to change is a competitive set that stops changing.

What it costs

Nothing in licence terms. Everything described on this page is standard configuration on an org you already run: an object that exists, two custom fields, one validation rule and three reports. The real cost is time, and it lands in three uneven pieces. A couple of hours for the configuration. Longer, sometimes much longer, for normalising the competitor values already sitting in a free-text field, which has to happen before any report is trustworthy. And two to four days for a backfill across four quarters, which is the piece that gets cut and the piece which is what settles whether a trend exists this quarter or twelve months from now.

The constraint that is never the software

If the field is empty in your org, no product will fill it. The search results around this topic are dominated by tools that integrate with the CRM to prompt reps for competitor data, and they are addressing adoption, which is a real problem and a different one. Adoption responds to two things: a rule that fires at the moment the answer is known, and a number published where the people filling in the field can see that it changed something.

There is one feature of this system that makes the usual advice sharper than it is elsewhere: a thousand characters, twice, on a field explicitly labelled weaknesses, offered to a seller at the moment they have just lost a deal. That is an invitation to write something candid into a record that is broadly readable inside the company, kept for years, and handed over as a matter of course in litigation and diligence reviews.

The test that resolves nearly every case is whether the sentence would survive being read aloud by somebody hostile, years later, with no context. It is not a rhetorical test here. Objects like these are exported in bulk during discovery or a diligence review, and whoever reads them afterwards has no way of telling which sentences reported a buyer and which vented a frustrated seller, unless the writing itself makes that obvious.

Three categories to keep out entirely. A rival’s confidential document, whatever route brought it to you: the existence and rough shape of a competing proposal can be recorded, the file and its terms cannot. Direct statements from a competitor about their own future prices, which turn an ordinary field into documentation of a contact that competition regulators treat seriously, and which are a difficulty in your process long before they are one in your org. And written assessments of named people at the rival, which are personal data and contribute nothing a description of their offer does not.

Stated positively the rule is shorter and produces better data anyway. Write down what the buyer reported the rival offering, in the buyer’s own wording, with a date attached. That version is defensible, checkable, and worth far more in a year than any assessment.

Everything above concerns deals you were in. A rival exists outside your pipeline for most of their life, and none of that reaches an opportunity record. Four gaps in particular, each with somewhere better to look.

• What kind of company they are becoming. Filed accounts, share allotments and directorships describe a business under compulsion rather than in a pitch, which is the closest thing to an audited view of a private rival. The jurisdictions and what each one discloses are under company registries.
• Where they are putting their people. A push into your best segment appears in their hiring months before it appears in your pipeline, and it appears in specifics you can act on. That method is under competitor hiring.
• What is coming next. An opportunity record learns about a rival’s roadmap when a buyer repeats a promise, which is both late and unverifiable. Ranked by how far ahead each one sees, the sources are under competitor roadmap.
• What it is like to work there. A reorganisation, a hiring freeze or a wave of departures changes how a rival competes long before the effect is visible in a deal, and employees describe it publicly. Glassdoor covers what that record does and does not support.

And one limit specific to the competitive fields rather than to the org. Both the object and the picklist record rivals somebody chose to record. Neither can surface a competitor nobody has heard of, and an absence in either reads exactly like an absence of competition. The only route to a name nobody typed in runs through the buyer’s own words, in notes and recordings, which is why the backfill is worth doing even in an org where the fields are well maintained.

Two clocks, because two different things decay here at different speeds and merging them is why most competitive reporting in this system lasts about three quarters.

Quarterly, circulate the three reports, denominators included, to the sellers completing the field, normalise any new spellings that have appeared, and read one quarter of the strengths and weaknesses text end to end. That reading is the part that gets skipped and the part that changes what sellers say, so put it in the calendar as a task rather than an intention.

Annually, audit the configuration rather than the data. Is the validation rule still firing on every record type. Has anyone added a record type without the related list. Have picklist values been retired, and if so does anybody know what the historic reports now mean. That last one is the quiet killer: deleting a rival from the value list removes them from every future report silently, and nothing in the interface records that the list ever contained them.

Off cycle, reopen immediately on three triggers. A rival turns up where your pipeline has never encountered them before. The pipeline stages are redefined, since stage-level timing is not comparable across that change. Or a competitor is acquired, because from that day on the name in your picklist and the company behind it are two different things and every historic comparison needs a note saying so.

The strengths and weaknesses text is written once, at the end of a deal, by somebody who is about to move on to the next one. Nobody ever goes back and revises it, and nothing about it changes when the rival does. So the corpus ages in an unusual way: it does not become obviously wrong, it becomes confidently repeated. The oldest entries are the ones that have been quoted most often, which makes them the ones a new seller is most likely to hear, and by then the claim they describe may have been withdrawn two releases ago.

The cost is a team arguing fluently against a competitor who no longer exists in that form, which is worse than arguing badly against the real one, because it comes with conviction and the buyer can check it. What prevents it is a second record that moves when the rival moves, kept outside the org and dated at every change. Maintaining that record is the whole purpose of competitive intelligence software, and it is what Flares does across pricing, product and messaging: a two-year-old line in a Weaknesses field can be tested against what the competitor says this morning before a seller repeats it. No platform decides whether the difference is material. A repricing that resets one segment barely registers in the next, and the person who can tell those apart is reading your own closed opportunities to do it.