How to Use HubSpot for Competitive Intelligence

Start from the form rather than from the data. When a seller closes a deal in HubSpot they are shown a set of properties, and what ends up in the portal is decided almost entirely by which of those properties exist and which are required. Everything else is downstream of that one design fact.

HubSpot’s documented defaults include a reason the deal was lost and a reason it was won. They do not include anything that names the company you lost it to. So the most common complaint about competitive data in this system, that nobody fills it in, describes a field that was never there. Meanwhile a second category of property has been filling itself in continuously and silently: a timestamp for the moment a deal arrived at each pipeline stage and the moment it left, written by the platform with nobody being asked for anything.

That split runs through the whole page. One half of a competitive picture, the identity of the rival, depends on a human decision that was never prompted. The other half, the shape and pace of the deal, is complete, automatic and almost never looked at. The method here is really just the work of joining the two.

1. 1Read the default deal properties before deciding what to build. HubSpot documents Closed lost reason and Closed won reason among its defaults and documents no property naming the competitor. Confirm that in your own portal first, because the gap is the project: everything else on this page assumes you know which of these fields already exists and which you are about to invent.
2. 2Add one competitor property, and choose its field type deliberately. A dropdown select stores one value, so a deal contested by two rivals forces a choice that quietly biases every count afterwards. Multiple checkboxes store several and make percentages harder to read. Pick the one that matches how your deals actually run, write down which you picked, and never change it mid year.
3. 3Backfill the name onto four quarters of closed deals. This is the step that pays for the project, and it is worth doing before any reporting. The stage timestamps on those old deals were recorded automatically at the time, so the name is the only missing column. Adding it turns a year of dormant timing data into a competitive dataset in an afternoon.
4. 4Build the timing view before the win rate view. Group closed deals by the competitor property and compare Days to close, then Cumulative time in each stage. The stage that stretches tells you where in your process a rival does their damage, and it is visible on far fewer deals than a win rate needs to be trustworthy.
5. 5Promote recurring rivals to company records with a labelled association. Once a name appears on enough deals to matter, create the company record and label the association so it means competitor rather than customer. The deals it touched are then one click from the record, and everything you learn about that company has somewhere to live other than a slide.
6. 6Export the deal set and keep a dated copy outside the portal. Exports run on every plan and let you choose which properties travel. Take the competitor property, the stage dates, amount and outcome, and keep each quarter's file. Reports get edited and filters get forgotten; a comparison nobody can reproduce is a comparison nobody will defend.

HubSpot publishes its default deal properties and the list is long: amount, close date, deal stage, probability, owner, the two closed reasons, and a family of automatically maintained timing properties covered further down this page. Read it looking for the competitor and you will not find one. That is a product decision rather than an oversight, and it is the same decision most CRMs have made: the competitive layer is something a company opts into.

Knowing that changes what the work is. It is not a data hygiene problem to be solved by asking people to be more diligent, because there is nothing for their diligence to land in. It is a twenty minute configuration change followed by a backfill, and the configuration is the easy part.

One property, and the field type is the real decision

Create a single deal property with a name nobody can misread, and choose its type deliberately, because HubSpot’s two enumeration types behave very differently here. A dropdown select stores multiple options where only one can be selected as the value. Multiple checkboxes store several at once. Both are perfectly reasonable and they produce different arithmetic.

With a dropdown, every deal has exactly one rival, deal counts by competitor add up to your total deal count, and every share you quote is a real share. The cost is that a three way evaluation is recorded as a two way one, and the name that gets dropped is systematically the less familiar of the two, which is usually the newer entrant you most want to know about. With checkboxes the record is honest and the percentages stop summing, so every figure has to state its denominator out loud or it will be misquoted within a week. The trade exists only because a property holds a value rather than a relationship. Systems that attach competitors to a deal as separate records sidestep it entirely, which is worth understanding before you commit and is worked through under Salesforce.

Two properties, because one cannot answer both questions

The instinct is to add competitor names to the existing closed lost reason list, and it costs you both questions at once. A list mixing price and budget with three company names cannot count your losses to a named rival, because a share of them went in as price, and it cannot count your price losses either, because a share of those went in as a company name. Split it: one property for the company that won, another for the cause the seller selected. Same twenty minutes, and both halves stay countable.

This is the part of the product that makes it worth writing about separately from every other CRM. HubSpot documents a set of properties per pipeline stage that nobody has to maintain: the date a deal entered the stage, the date it exited, the cumulative time it has spent there, the time since it last entered, the time in the current stage, and days to close as the interval between creation and closing. Every one is written by the system.

Read against a competitor property, those clocks answer a question a win rate cannot. Win rate tells you the outcome of a contest. The clocks tell you what the contest cost you regardless of who won it, and they say where in your own process it happened.

The stage that stretches is the finding

Group closed deals by the competitor property and compare cumulative time in each stage against your baseline, meaning deals where the property was blank or set to no competitor. What comes back is rarely a uniform slowdown. One stage stretches and the others do not, and which stage it is has a specific reading.

• Discovery stretches. The buyer is still working out what the category is, and a rival is helping define it. That is a positioning problem long before it is a product one.
• Evaluation or demo stretches. A feature comparison is being run and yours is not winning it quickly. This is the stage where a product gap shows up as time rather than as a lost deal.
• Proposal or negotiation stretches. You are being used to move a price, either theirs or yours. The deals you win here are worth checking for discount depth, because winning slowly and cheaply is a loss with better paperwork.
• Nothing stretches, but days to close rises. The delay is between stages rather than inside one, which usually means the buyer went quiet while somebody else was in the room.

The reason to build this view before the win rate view is sample size. A win rate against one rival needs dozens of closed deals before a single outcome stops moving it several points. A median time in stage is readable from a handful, because it is comparing distributions rather than counting successes, and the direction shows up long before the outcome does.

Why the history exists even where the name does not

The stage timestamps were being recorded on every deal your portal has ever run, including the ones closed two years ago by people who left. They were never a competitive dataset because the column that would make them one was missing. Supply that column retrospectively and the timing comes with it at no extra cost, which is why the backfill step earlier on this page is the single highest-return hour in this whole method.

A property value is a string. It cannot hold a note, a file, a contact, a date you last checked something, or a link to the fourteen deals it appeared on. Once a rival shows up often enough to matter, the string stops being enough, and HubSpot has a route to something better that most competitive setups never use.

Create the competitor as a company record and label the association between that company and the deal. HubSpot documents association labels as a way of defining what a relationship means, supports them across CRM object pairs, allows up to fifty labels per pair, requires Super Admin permission to create them, and lets them be used in segments, reports and workflows. Custom labels need a Professional or Enterprise subscription. Labelling a company to deal association as competitor rather than customer gives you a report that asks which deals a named rival appeared in without touching a property at all.

The pay off is that everything you learn about a competitor has somewhere to live other than a slide deck. Their pricing page as of a date, the claim your sellers keep hearing, the note from the win you took off them last quarter: all of it attaches to one record, and the deals are one click away in either direction.

Ten items sit in the table above with a grade against each. Here is what they are actually for, arranged by how the data arrives, because that is what decides how far it can be trusted.

The two properties the whole analysis rests on

The custom competitor property. Everything else here is a cut of this one column. Keep the option list short, controlled, and wide enough to cover the outcomes with no vendor in them: no decision, an internal build, and other. Skim what falls into other every quarter, because a name that keeps landing there is a company nobody has added to the list yet.

Closed lost reason. A default property whose option list is yours to define, recording what the seller who lost selected at the moment they marked the deal closed. That is a genuine finding about your sales team’s model of the market, and it is not evidence about the buyer’s decision. Whoever wrote the option list has enormous influence over what the portal appears to say, so read the list before reading the report.

The clocks nobody has to remember to start

Date entered and date exited each stage. The raw material for everything in the timing section above, written per stage per deal, and the reason a backfill of the competitor name unlocks history rather than starting a count from zero. Cumulative time in a stage and latest time in a stage differ in a way worth knowing: the first totals every visit, the second measures only since the deal last entered, so a deal that bounced back from evaluation to discovery reads very differently through each. Days to close is the coarsest of the family and the one a board will actually look at, which makes it the right headline and the wrong diagnostic.

The commercial columns, and what they will not tell you

Amount, deal probability and weighted amount. Probability is attached to the pipeline stage rather than to anything anybody judged about this deal, and weighted amount is simply the two multiplied, so neither carries information about a competitor. What they are good for is sizing: how much pipeline is currently contested by each named rival, which is the number that decides whether a competitive programme gets funded. Closed won reason is the companion property almost nobody configures, and it is the only structured place your own side of a head to head gets recorded. A team that knows why it wins against a rival can teach that; a team with only loss reasons can only worry.

Where the rival is actually named

Notes, calls, emails and meetings on the record. On every deal that closed before the property existed, this is where the competitor’s name is, which makes it the raw material for the backfill. It also holds what no structured field ever captures: the offer the rival made, the point at which they appeared, and the buyer’s own phrasing. The fuller treatment of that material as a source in its own right is under sales call recordings.

The two structures that turn values into objects

Labelled associations to a company record promote a rival from a string to a thing, as set out above. The custom report builder is what joins deals to those companies, to contacts and to activity in a single report, across up to five sources, and it is documented for Professional and Enterprise. Below that tier the join happens in a spreadsheet instead, which the next section is about.

Export is unusually generous here, which is fortunate, because on the lower tiers the export is not a fallback but the main route. The artefact you are aiming at is one row per closed deal with the competitor name beside the timing, and it is the same artefact whether you build it in a report or in a spreadsheet.

The columns to take

Deal name, close date, outcome, amount, the competitor property, the closed lost or won reason, days to close, and the cumulative time in each stage that matters to you. Nine columns is enough for every cut described on this page, and the discipline is to take the raw values rather than anything pre-aggregated, because a pivot you built yourself can be re-cut and a chart somebody exported cannot. A ready-made version of those columns sits in the competitor tracking spreadsheet, which saves an hour of layout arguments.

How the file comes out

HubSpot documents record exports in CSV, XLSX and XLS, with a choice between the properties in your current view, all properties on the records, or all properties and associations. The file arrives as an emailed download link. The published ceilings are far above anything this work needs: up to three hundred exports in a rolling twenty four hour window and three running at once, with large files split only past a million rows. In practice that means you can afford to export a fresh copy every time somebody questions a number, which is a better habit than defending an old one.

Reporting inside the portal, if your tier allows it

The custom report builder is documented for Professional and Enterprise across the Hubs and joins up to five sources in a single report, which is what lets a competitor cut include company attributes and activity rather than deal properties alone. Where that is available, build the four standing views there so they refresh on their own, and reserve the export for anything you need to join to data the portal has no way to hold, whether that is buyer interview notes or a rival’s current price list.

And the third route, which is not an export at all

Everything above moves your own records around. The material a portal structurally cannot hold, meaning anything a rival did, has to come from somewhere else, and for teams who want it continuously rather than in a quarterly scramble that somewhere is a competitive intelligence platform, joined to the CRM on a supported integration so the findings land against companies and deals that already exist. Two honest caveats. It adds nothing to the timing analysis on this page, which is already complete. And it will not populate a property nobody created.

What works on any plan

Creating the competitor property, filling it in, requiring it through the deal form, reading the automatic stage timing, filtering and sorting the deal index by any of it, and exporting the result. That is the entire data layer, and it costs nothing beyond the licence you already hold. A team on a starter tier can run every method on this page provided somebody is willing to open a spreadsheet.

What sits behind Professional or Enterprise

Three things, and they are all analysis rather than collection. The custom report builder, which is the multi source join. Calculation properties, which is how a discount percentage or a derived stage duration becomes a column rather than a formula somebody re-types. And custom association labels, which is what makes the company record route work properly. None of them changes what your portal knows; all of them change how quickly you can ask it something.

Permissions worth asking for by name

Property creation and edit access on deals, so the field can be maintained without a ticket. Export permission, since that is the difference between doing the analysis and requesting it. And Super Admin involvement once, if you are going the association label route, because label creation is documented as requiring it. Ask for the narrow reporting access over closed deals rather than broad record access. It is far easier to approve, and it leaves open deals alone, which is normally the real substance of the objection.

The effort, honestly

An hour to create the properties and set the requirement. Two to four days for a serious backfill of four quarters, which is the part that gets cut and the part that decides whether you have a trend now or next year. Then roughly half a day per quarter to produce and publish the numbers, which is the only recurring cost and the one nobody budgets for.

The records are yours, so the questions about how material was obtained mostly do not arise. The questions that do arise are specific to this system, and they come from the same feature that makes it useful: a portal is a marketing platform and a CRM at once, and things written into one side are reachable from the other.

• A competitor company record is one filter away from an audience. This is the risk that is unique to running competitive tracking inside a marketing platform, and it is entirely preventable. Exclude the competitor label from every list, sequence and workflow at the moment you create the first record, and check the exclusion against a real send before you trust it.
• A rival’s employees are personal data and add nothing to the picture. Creating contact records for them collects personal data you have no relationship-based reason to hold, and it teaches everybody that the contacts object doubles as a research file. Track the company, not the people who work there.
• A workflow will act on a competitor record without hesitating. Automation in a portal is deliberately indiscriminate: enrolment criteria match properties, not intentions. Any workflow that could touch a company record needs the competitor label in its suppression criteria, and the ones written before you started this exercise are the ones worth re-reading first.
• Association labels are visible to everyone with a seat. Labelling a relationship as competitor is a public statement inside your company, which is fine, and it means the label vocabulary is worth choosing carefully. Descriptive terms age well. Judgemental ones turn up in screenshots.

The ordinary boundaries hold here as they do in any system of record: confidential material belonging to a rival never gets pasted into a note, and a competitor talking to you directly about their own future prices is a difficulty in your process long before it is a difficulty in your portal.

State the boundary before anybody builds a programme on top of this: a portal holds a complete record of the deals you were part of and nothing at all about what a rival did. Four specific gaps come out of that, and each has a better place to look.

• Where they are investing. New markets, new functions and new product bets are visible in hiring months before they reach a sales conversation, and the posting spells out what they intend to build, worked through under job postings.
• What they are about to ship. A deal record learns about a rival’s next release when a buyer repeats a promise a seller made them, which is late and second hand. Ranked by lead time, the real sources are under competitor roadmap.
• How their customers actually feel. A portal holds the views of buyers who picked you, or came close to it. Anyone who picked the rival and came to regret it publishes that verdict somewhere public instead, which is where review sites.
• Whether they can afford the fight. A rival discounting hard for two quarters is either buying the market or running out of road, and your deal records cannot distinguish those. Money raised and when is covered under competitor funding.

There is one further limit specific to this system rather than to CRMs generally. Because competitor company records live in the same object as customers, a portal that has been used for competitive tracking for a year contains a competitive picture assembled entirely from companies somebody manually decided to add. Nothing in it will ever surface a rival nobody typed in, and the interface gives no hint that anything is missing.

The maintenance mechanism here is publication rather than validation, and it is worth being blunt about it. A property whose output is never shown back to anybody rots inside two quarters whatever the form does, because completing it is unpaid work for the person completing it. Show the team a pricing rule or an enablement asset that changed because of the field and it stays populated.

Quarterly, produce the numbers with their denominators and the coverage rate at the top, circulate them to the people who fill the property in, and run one audit pass over the deals where the property is blank or set to other. Blank and other are where the data quality problem always sits, and a name that keeps landing in other is the one early warning this system can produce unprompted.

Reopen off cycle on three triggers rather than waiting for the quarter. A rival turns up on a deal in a segment nobody had seen them in before. Somebody restructures the pipeline, since stage level timing cannot be compared either side of that change, so any chart crossing it is quietly wrong. Or somebody edits the option list, which rewrites the meaning of every value already recorded and leaves nothing behind to say so, which is why the list deserves change control and a date against each edit.

Every property discussed here describes a company by its name and nothing else. The value reads the same in January and in November, and in between the company behind it can have changed its entry price, rebuilt its positioning, entered a segment it never served and shipped the feature your sellers had been told it lacked. Your portal records that the rival was present. It has no way of recording who they were at the time, and no field anywhere in it notices when that changes.

The cost arrives as confident briefings built on definitions that expired quietly: a battlecard describing a product two releases old, an objection response for a price that was withdrawn, sellers arguing against positioning the competitor abandoned last spring. Fixing that needs the name to acquire a version, maintained outside the portal and stamped with dates, which is the job competitive intelligence software was built for. Flares holds that version: the wording a rival’s pricing page, product pages and homepage actually carried, and the day each of those sentences moved. What no software can hand you is the part your portal already has. No outside system has any idea which of your deals were contested, what they eventually closed at, or how much room you gave up to keep them, and a dated change with none of that beside it is only news.