Competitive intelligence program · 13 min read · Updated 2 Aug 2026
Competitive Intelligence Request Brief Template (Free)
A blank competitive intelligence request brief you can fill in today, plus the guidance for what belongs in each field. It is the intake form a stakeholder completes before any research starts, and its job is to stop open-ended requests from consuming weeks and producing something nobody uses.
Copy pastes straight into Google Sheets or Excel with the columns intact. Downloads are free with a work email.
The competitive intelligence request brief template
This is exactly what you get when you copy or download. Blank fields are yours to fill in; each table ships with one example row to show the pattern, which you delete.
Request details
Filled in by the requester, not the CI team. If this takes more than ten minutes, the request is probably not ready to be made.
- Requester and teamNamed person, with their function
- Date raisedThe day the request was submitted
- Needed byA real date, tied to the decision rather than to a preference
- Competitors or market in scopeNamed. "Our competitors" is not a scope
- One-line summary of the requestWhat you want to know, in a sentence
- Urgency and whyWhat is happening on that date that makes this the deadline
1. The decision this informs
First row is an example, delete it. If this table cannot be completed, stop here. A request with no decision behind it is a reading assignment.
| The decision to be made | Who makes it | When it gets made | What we would do differently depending on the answer |
|---|---|---|---|
| ExampleWhether to match a competitor's free viewer seats | CEO, with the pricing group | 31 Oct, before renewals season | Change seat packaging, or keep it and retrain the team on total cost |
2. The questions, ranked
First row is an example, delete it. Three to five, numbered by importance. The answer to question one should be worth the whole request on its own.
| Rank | Question | Why this matters to the decision | What a useful answer looks like |
|---|---|---|---|
| Example1 | Which tiers of theirs include viewer seats at no cost, and with what limits? | Determines whether matching is a small change or a repricing | The tiers, the caps, and where each is published |
3. What we already believe
First row is an example, delete it. Complete this table before anyone starts researching, including the beliefs you hold loosely.
| What we believe | Where that came from | Confidence | Would being wrong change the decision? |
|---|---|---|---|
| ExampleTheir viewer seats are free with no cap | A rep mentioned it after a lost deal in June | Low, one second-hand report | Yes, a cap would make matching much cheaper |
4. How the answer will be used
First row is an example, delete it. Name the artifact and the audience. The same finding becomes a different document depending on who reads it.
| Output needed | Audience | Where it will live | Who presents it |
|---|---|---|---|
| ExampleTwo slides in the pricing review | CEO and the pricing group | The 31 Oct pricing deck | Maya R., Product Marketing |
5. Effort, sources and constraints
First row is an example, delete it. Both sides sign off on these numbers at intake, and the last column is the one that matters when the ceiling is hit.
| Constraint | Detail | Set by | Consequence if exceeded |
|---|---|---|---|
| ExampleTime budget | Two working days maximum | Agreed with the requester | Come back with a partial answer rather than a late one |
6. What good looks like
First row is an example, delete it. Three or four rows describing properties of the answer, not its conclusions. Agree them at intake.
| Criterion | Threshold | How it will be checked |
|---|---|---|
| ExampleEvery figure traces to a primary source | 100% of published pricing claims | The sourcing column in the delivered document |
7. CI team triage
Completed by the intelligence team, not the requester. First row is an example, delete it. Declining and refining are both legitimate outcomes.
| Verdict | Reason | Owner | Estimated effort | Delivery date |
|---|---|---|---|---|
| ExampleAccept, narrowed | Questions 1 and 2 are answerable from published sources; 3 is not | Tom A., Competitive Intelligence | 1.5 days | 24 Oct |
8. Outcome, owners and dates
First row is an example, delete it. Completed after delivery. This is the table that tells you whether the request was worth answering.
| What we found | Decision it produced | Owner | Date | Was the request worth it? |
|---|---|---|---|---|
| ExampleViewer seats are free but capped, and the cap is published | Match with a cap of our own rather than repricing | Elena V., CEO | 31 Oct | Yes, it changed the decision from repricing to a capped tier |
How to fill in your competitive intelligence request brief
How to scope a competitive intelligence request brief
The requester fills this in, not the intelligence team, and that division is the whole point of the artifact. A brief completed by the analyst on the requester's behalf reproduces the analyst's assumptions about what was wanted, which is exactly the failure it exists to prevent. Ten minutes of the requester's time routinely saves several days of the team's, and a request that cannot survive ten minutes of specification usually should not be made yet.
Requester and team
A named person rather than a function. Requests arriving from a team have nobody to go back to when a question turns out to be ambiguous, and ambiguity surfaces in almost every request at some point.
Date raised
Useful mainly in aggregate. Reviewing raised dates against delivery dates over a quarter is the cheapest way to see whether the intelligence function is keeping up with demand or quietly falling behind.
Needed by
Tied to a real event rather than to a preference. "As soon as possible" is not a deadline and it competes badly against requests that name a date, which means it tends to get served last.
Competitors or market in scope
Named. "Our competitors" is not a scope, and the difference between researching two named rivals and researching a category is roughly a factor of ten in effort.
One-line summary of the request
What you want to know, in a sentence. If the sentence needs a semicolon and an and, the request is probably two requests and should be split, since they will have different deadlines and different answers.
Urgency and why
What happens on that date. Urgency with a reason can be prioritised against other work; urgency without one is indistinguishable from preference, and treating every request as urgent is how an intelligence function stops being able to do anything strategic.
How to name the decision behind an intelligence request
If this table cannot be completed, stop. A request with no decision behind it is a reading assignment, and reading assignments are how intelligence teams end up producing documents that are read once and change nothing. This is not bureaucratic gatekeeping: the decision determines what counts as an answer, what depth is warranted and when the work is finished. Without it, none of those can be judged by either side.
The decision to be made
Phrased as a choice: "whether to match a competitor's free viewer seats". Not "understand their pricing", which is a topic. Topics have no completion criteria, so research against them expands until someone loses patience.
Who makes it
A named person with the authority. If nobody in the organisation can actually make this decision, the research will be interesting and inert, and it is better to discover that before the work than after it.
When it gets made
The decision date drives the deadline, not the other way round. Intelligence delivered after the decision has been taken is an audit rather than an input, however good it is.
What we would do differently depending on the answer
The most valuable row in this template and the one that most often kills a request. If the answer is the same whatever the research finds, the decision has already been made and the request is seeking justification rather than information. Saying so early is a service to everybody.
Some requests legitimately have no decision
Standing awareness, onboarding a new executive, or a periodic landscape refresh are real needs. Mark them explicitly as awareness rather than decision-support, so they can be scheduled against spare capacity instead of competing with deadline-driven work.
How to write the questions in a competitive intelligence request brief
Three to five questions, numbered by importance, and the ranking is the part that matters. Almost every request runs out of time before it runs out of questions, so the order decides what actually gets answered. A useful discipline: the answer to question one should be worth the whole request on its own. If it is not, the important question has not been written down yet.
Question
Specific and answerable: "which tiers include viewer seats at no cost, and with what limits?". Compare that with "what is their pricing strategy?", which cannot be answered from any source and will be met with a document rather than an answer.
Why this matters to the decision
One line linking it to the decision table. Questions that cannot be linked are curiosity, which is legitimate but should be labelled so it can be dropped first when time runs short.
What a useful answer looks like
Describe the shape of the answer: "the tiers, the caps, and where each is published". This is what lets the analyst know when they are finished, and it prevents the common outcome where a thorough answer to a slightly different question arrives on the deadline.
Rank them honestly
Not by how interesting they are but by how much they move the decision. Requesters routinely rank the question they are most curious about first and the one that determines the outcome third.
Distinguish what is knowable from what is not
Published pricing, packaging and headcount signals are knowable. A competitor's internal roadmap, margins and intentions are generally not, and no amount of effort changes that. Marking the difference at the request stage prevents a fortnight spent producing a confident guess.
How to record what you already believe
Write down what you think is true before the research starts. This section does two jobs at once. It stops the team spending a day confirming something the requester already knew, which is a common and entirely avoidable waste. And it surfaces the low-confidence beliefs that are quietly driving the decision, which are frequently the real reason the request exists even when the requester has not framed it that way.
What we believe
Stated plainly, including the things you are not sure about. Beliefs held loosely still shape decisions, and an unwritten assumption cannot be tested by anybody.
Where that came from
A rep's comment after a lost deal, a competitor's website, something heard at a conference. Provenance predicts reliability well, and second-hand accounts of competitor behaviour are wrong often enough to be worth flagging.
Confidence
High, medium or low. A low-confidence belief driving a large decision is the single best justification for a research request, and naming it that way makes the request easy to prioritise.
Would being wrong change the decision?
The filter. Beliefs that would not change the decision if false do not need verifying, however uncertain they are. Beliefs that would change it are the actual scope of the request, and this column often shortens the question list considerably.
Expect some beliefs to be wrong
That is the point. Requests where every stated belief is confirmed tend to be requests that were not needed. The value of an intelligence function shows up disproportionately in the corrections.
How to state how the answer will be used
Name the artifact and the audience, because the same finding becomes a genuinely different document depending on who reads it. Two slides for an executive pricing review and a working note for a product manager require different depth, different framing and different amounts of caveat. Analysts who are not told the destination default to the thorough version, which is the wrong output for most requests and the slowest one to produce.
Output needed
Be concrete: two slides, a one-page brief, three rows in an existing tracker, a verbal answer in a meeting. A verbal answer is a legitimate and under-used output that takes an hour rather than a day.
Audience
Who reads it, and whether they will read it with you in the room. A document that has to stand alone needs far more context than one you will present, and the difference is real work.
Where it will live
A specific deck, a wiki page, a battlecard, a tracker. Findings with no destination are the ones that get delivered and then vanish, which is demoralising for the team and invisible to everyone else.
Who presents it
Often the requester rather than the analyst. Naming this early changes how the output is written, since a requester presenting someone else's research needs the reasoning made explicit rather than compressed.
How to set effort and source constraints
Agree the ceiling before the work starts. Research without a stated limit expands to fill whatever time exists, and the expansion is rarely proportionate to the value added: the second day usually adds far less than the first. Setting the budget as part of the request converts an open-ended assignment into a bounded one, and it gives the analyst permission to return with a partial answer on time rather than a complete one late.
Time budget
In working days, agreed with the requester. Most competitive questions worth asking can be answered usefully in one to two days, and the ones that genuinely need a fortnight should be recognised as projects rather than requests.
Sources that are off-limits
Any method the organisation will not use. Public sources, published documentation, product trials under your own identity, review sites and conversations with customers who use both products cover nearly every question worth asking. Anything requiring misrepresentation is out, and stating that in the brief avoids an awkward conversation later.
Budget for paid sources
Analyst reports, data subscriptions or expert-network calls, where they apply. Naming a figure of zero is also useful information, since it rules out a class of answers before anyone goes looking for them.
Consequence if exceeded
Decide in advance what happens: return partial, escalate for more time, or drop the lowest-ranked questions. Requests without this default to silence followed by a late delivery, which is the worst of the available options.
Confidentiality
Whether the request itself is sensitive. Some questions reveal strategy by being asked, and a brief circulated in a shared workspace is a broader disclosure than the requester may have intended.
How to define what good looks like
Write the definition of done before the work starts, so neither side has to guess when it is finished. This is the section requesters most often skip and analysts most often wish existed. Without it, the analyst optimises for thoroughness because thoroughness is unfalsifiable, and the requester judges the output against an unstated standard that the analyst could not have known. Both problems disappear with three or four written criteria.
Criterion
What the answer must have: every figure traced to a primary source, all named competitors covered, a clear statement of what could not be determined. Criteria describe properties of the answer, not its conclusions.
Threshold
Where a threshold applies: 100% of pricing claims sourced, all three named competitors covered, confidence stated on every inference. Vague criteria are as unhelpful as no criteria.
How it will be checked
Usually visible in the delivered document itself, such as a sourcing column. Checks that require a separate verification step do not happen, so build them into the output format.
Include what may be left unanswered
Explicitly permit the analyst to return "we could not determine this, here is why". Without that permission, unanswerable questions get answered anyway with a confident guess, which is worse than an acknowledged gap and considerably harder to unpick later.
How the intelligence team should triage a request
This section is completed by the intelligence team, and declining is a legitimate outcome. A team that accepts every request in the order it arrives will spend its capacity on whoever asks most loudly, which correlates poorly with what matters. Triage is not gatekeeping for its own sake: most declined requests are declined because the question is unanswerable, already answered, or attached to a decision that has already been made.
Verdict
Accept, accept narrowed, refine and resubmit, or decline. Accept-narrowed is the most common correct answer, since requests routinely contain two answerable questions and one that no source could settle.
Reason
One line, always, including on acceptance. Reasons make the triage decision reviewable and they teach requesters what a good request looks like faster than any amount of process documentation.
Owner and estimated effort
Named analyst and days. Estimates recorded against actuals over a quarter are the only reliable way to learn how long this work really takes, and the first quarter's estimates will be optimistic.
Delivery date
Committed, and before the decision date rather than on it. A finding arriving the morning of the decision cannot be absorbed, questioned or acted on properly.
Decline when the answer already exists
The most common and most useful decline. Much of what gets requested has been answered in a report from last quarter, and pointing at it takes minutes. A team that tracks its own past answers declines a surprising share of incoming work this way.
How to close the loop on a competitive intelligence request
Completed after delivery, and this is the table that tells you whether the request was worth answering. Intelligence functions are notoriously hard to justify at budget time because their output is documents rather than revenue. A log of requests, the decisions they produced and an honest verdict on whether each was worth the effort is the most persuasive artifact such a team can maintain, and it takes about two minutes per request.
What we found
The headline finding in one line, including when it contradicted the stated belief. Corrections are where the value concentrated, so they are worth recording distinctly.
Decision it produced
The actual decision taken. Requests that produced no decision should be recorded as such, honestly, since that pattern is what tells you the intake process needs tightening.
Owner and date
Who decided and when. This also closes the loop with the decision table at the top, and a systematic gap between the two is a finding about the organisation rather than about the request.
Was the request worth it?
A one-line verdict, written by the requester rather than the analyst. Over a quarter this produces a genuinely useful picture of where the function creates value, and it is far more credible than a self-assessment.
Review the log quarterly
Look for requests that produced no decision, requests answered too late to matter, and the same question arriving repeatedly. Each pattern points at a different fix, and none of them is visible from any single request.
Sourcing and upkeep: making a request brief worth filling in
These rules apply to every section above. This artifact fails in one specific way: it becomes a form. Once a request brief is experienced as bureaucracy, stakeholders route around it, ask the analyst directly, and the intake process quietly dies while continuing to exist on paper. The habits below keep it on the useful side of that line, which is roughly ten minutes of the requester's time in exchange for a visibly better answer.
Ten minutes, not an hour
If the brief takes longer than the conversation it replaces, it will be avoided and should be shortened. The decision table and the ranked questions carry most of the value; everything else can be brief.
The requester fills it in
A brief written by the analyst on the requester's behalf encodes the analyst's assumptions about what was wanted, which is the exact failure the artifact exists to prevent.
No decision, no request
The single rule that changes the most. Awareness requests are legitimate but should be labelled as such and scheduled against spare capacity, not run against a deadline.
Separate the knowable from the unknowable early
Published pricing, packaging, hiring signals and product behaviour are knowable. Internal roadmaps, margins and intentions generally are not. Naming which is which at intake prevents a fortnight spent producing a confident guess.
Use public and permissioned sources only
Published material, documentation, trials under your own identity, review sites and customers who use both products answer nearly every question worth asking. Note this in the constraints so nobody has to raise it awkwardly mid-request.
Declining is part of the job
Requests that are unanswerable, already answered, or attached to a decision already taken should be declined with a reason. Teams that accept everything serve whoever asks loudest.
Keep the log and read it quarterly
Requests, decisions produced and an honest worth-it verdict. This is the most persuasive artifact an intelligence function can bring to a budget conversation, and it costs two minutes per request.
A competitive intelligence request brief example
You are head of product marketing at Pipedrive. The CEO wants to know whether to match HubSpot's free view-only seats before renewals season, and you raise it with the competitive intelligence team properly rather than in a message. This is that brief, filled in.
Published pricing and packaging verified 2 August 2026, from the companies’ own pages rather than third-party round-ups, which frequently conflate annual and monthly prices. Pricing changes without notice, so re-check before quoting any of it.
Sections marked illustrative are invented for this example. Win rates, deal counts, discounting behaviour, customer quotes, owners and internal dates are not published by HubSpot, Pipedrive or anyone else, so those rows are a plausible fictional scenario rather than reported fact, and should not be read as claims about how either company performs or negotiates. Everything else comes from the two pricing pages linked below, read on the date shown.
Request detailsIllustrative
| Field | Example entry |
|---|---|
| Requester and team | Maya R., Product Marketing |
| Date raised | 5 Oct 2026 |
| Needed by | 24 Oct 2026, a week before the pricing decision |
| Competitors or market in scope | HubSpot Sales Hub only. Not the wider suite |
| One-line summary of the request | What exactly do their free view-only seats include, and what are the limits? |
| Urgency and why | Renewals season starts 15 Nov and the packaging decision is set for 31 Oct |
1. The decision this informsIllustrative
| The decision to be made | Who makes it | When it gets made | What we would do differently depending on the answer |
|---|---|---|---|
| Whether to introduce a free read-only seat tier of our own | Elena V., CEO, with the pricing group | 31 Oct 2026 | Introduce a capped free tier, match uncapped, or keep current packaging and retrain on total cost |
2. The questions, rankedIllustrative
| Rank | Question | Why this matters to the decision | What a useful answer looks like |
|---|---|---|---|
| 1 | Which of their tiers include view-only seats at no cost, and is there a cap? | A cap makes matching a small change; no cap makes it a repricing | The tiers, any caps, and the published page each appears on |
| 2 | What do their view-only seats actually permit, beyond viewing? | If they can run reports, the gap is wider than we have assumed | A capability list from their documentation, not from their marketing |
| 3 | How does the total cost compare at 40 seats with a 30/10 edit-to-view split? | This is the comparison our reps are getting wrong in live deals | A worked total for both vendors, currencies stated as published |
| 4 | Have they changed this packaging in the last 18 months? | A recent change would suggest it is a deliberate wedge rather than a legacy choice | Dated evidence of the change, or a statement that we could not establish it |
3. What we already believeIllustrative
| What we believe | Where that came from | Confidence | Would being wrong change the decision? |
|---|---|---|---|
| Their viewer seats are free with no cap at all | A rep mentioned it after a lost deal in June | Low, one second-hand report | Yes. A cap would change this from a repricing to a small packaging change |
| Free viewers are available on every paid tier | Assumed internally, never checked | Low, nobody can say where this came from | Yes, if it is entry-tier only the threat is much smaller |
| This decided four of our five mid-market losses last quarter | Win/loss interviews, Q2 2026 | High, stated independently by four buyers | No, this is the reason for the request rather than a question |
4. How the answer will be usedIllustrative
| Output needed | Audience | Where it will live | Who presents it |
|---|---|---|---|
| Two slides plus a one-page appendix | CEO and the pricing group | The 31 Oct pricing deck | Maya R., Product Marketing, so the reasoning needs to be explicit |
| Three rows in the competitor tracker | The competitive intelligence team | The standing tracker, whatever the decision | Tom A., Competitive Intelligence |
5. Effort, sources and constraintsIllustrative
| Constraint | Detail | Set by | Consequence if exceeded |
|---|---|---|---|
| Time budget | Two working days maximum | Agreed with Tom A. on 5 Oct | Return a partial answer rather than a late one |
| Sources off-limits | No signing up under a false identity, no approaching their staff | Standing rule in the CI charter | Not applicable, the questions are answerable from published sources |
| Budget for paid sources | Zero | Maya R. | Rules out analyst reports; not needed for these questions |
| Confidentiality | Normal. The brief can sit in the shared workspace | Maya R. | Not applicable |
6. What good looks likeIllustrative
| Criterion | Threshold | How it will be checked |
|---|---|---|
| Every figure traces to a primary source | 100% of published pricing and packaging claims | The sourcing column in the delivered document |
| Currencies recorded as published, not converted | Every price | Visible in the comparison table |
| Anything undeterminable is stated as such | No confident guesses on question 4 | An explicit could-not-determine line where it applies |
7. CI team triageIllustrative
| Verdict | Reason | Owner | Estimated effort | Delivery date |
|---|---|---|---|---|
| Accept, narrowed | Questions 1 to 3 are answerable from published sources. Question 4 probably is not, and will be attempted last | Tom A., Competitive Intelligence | 1.5 days | 22 Oct 2026, two days earlier than requested |
8. Outcome, owners and datesIllustrative
| What we found | Decision it produced | Owner | Date | Was the request worth it? |
|---|---|---|---|---|
| View-Only Seats are free and assignable, confirmed on their published pricing page | Matching is a packaging decision, not a repricing | Elena V., CEO | 31 Oct 2026 | Yes. It moved the decision from repricing to a capped free tier |
| The belief that there is no cap could not be confirmed either way from published sources | Proceed with a cap of our own and revisit if evidence appears | Elena V., CEO | 31 Oct 2026 | Yes, and the honest non-answer was more useful than a guess would have been |
| Question 4 was not answerable within the time budget | Dropped, recorded as undetermined rather than inferred | Tom A., Competitive Intelligence | 22 Oct 2026 | Yes, dropping it on time beat delivering a guess late |
How to roll out your competitive intelligence request brief
- 1Copy or download the blank brief. Use Copy to paste it straight into Google Sheets or Excel with the columns intact, or download the CSV, Notion or PDF version.
- 2Have the requester fill it in, not the analyst. A brief written on the requester's behalf encodes the analyst's assumptions, which is the exact failure the artifact exists to prevent.
- 3Delete the example rows. Each table ships with one example row so the pattern is obvious. Remove it before you circulate the brief.
- 4Name the decision before anything else. If nobody can say what would be done differently depending on the answer, stop. The decision has already been made or there is not one.
- 5Rank three to five questions by decision impact. Not by curiosity. Most requests run out of time before they run out of questions, so the order decides what actually gets answered.
- 6Write down what you already believe, and how sure you are. This stops the team re-discovering what you knew, and it surfaces the low-confidence beliefs that are quietly driving the decision.
- 7Agree a time budget and what happens if it is exceeded. Partial and on time beats complete and late. Research without a stated ceiling expands to fill whatever time exists.
- 8Let the CI team triage, then close the loop after delivery. Accept, narrow, refine or decline with a reason, then record what decision the answer actually produced.
Competitive intelligence request brief FAQ
What is a competitive intelligence request brief?
A competitive intelligence request brief is the intake form a stakeholder completes before any research starts. It records the decision the answer will inform, three to five ranked questions, what the requester already believes and how confident they are, how the answer will be used, the time budget, and what a good answer must contain. The intelligence team then triages it: accept, narrow, refine or decline. It takes about ten minutes and routinely saves days.
Why do competitive intelligence requests need a brief?
Because the failure mode of an intelligence function is not producing bad answers, it is producing thorough answers to slightly different questions than the ones that mattered. An open request such as "tell me about Competitor X" has no completion criteria, so the analyst optimises for thoroughness and the requester judges the result against an unstated standard. Naming the decision fixes both problems at once: it tells the analyst what counts as an answer, and it tells the requester when to expect one.
What are the parts of an intelligence brief?
Worth separating two things that share the name. A request brief, which this template covers, is the input: decision, ranked questions, existing beliefs, intended use, constraints and success criteria. A finished intelligence brief is the output, and it typically carries a bottom line up front, the key judgements with confidence levels, the supporting evidence, what remains unknown, and the implications or recommendation. Our executive brief template covers the output side.
What makes a good intelligence report?
It answers a question somebody actually asked, leads with the judgement rather than the method, distinguishes clearly between what was observed and what was inferred, states confidence on every inference, and says plainly what could not be determined. The last of those is the most reliable marker of quality. Reports with no acknowledged gaps have usually filled them with confident guesses, and a single guess that turns out wrong discredits the sourced findings sitting next to it.
How do you write an intelligence report?
Start with the answer, not the approach. Open with the judgement in one or two sentences, then the evidence, then the method and its limits at the end. Mark every claim with its source and date. Label inferences as inferences and attach a confidence level. Include what you could not determine and why. Finish with implications or a recommendation rather than a summary, since a summary restates what the reader has just read while a recommendation gives them something to act on.
What are the 4 phases of intelligence?
There is no single canonical count, and the agencies that invented the concept do not agree. The CIA describes five phases: planning and direction, collection, processing, analysis and production, and dissemination. The FBI describes six, splitting out requirements at the front. Four-phase and six-phase versions with feedback loops both circulate. The useful point is not the number but the shape: intelligence starts with a stated requirement and ends with something a decision-maker can use, which is exactly what a request brief formalises.
What are the 7 basic principles of intelligence?
No canonical seven exists. The phrase comes from military and government doctrine, and different doctrines enumerate differently, so lists presented with confidence online rarely trace to a single source. Principles that do recur across serious treatments are worth knowing: intelligence must serve a decision-maker, timeliness beats completeness, sources and methods should be recorded, analytic judgements should carry confidence levels, and mirror-imaging is the most common analytic error. Those are defensible; the numbered list is not.
What are the 15 axioms for intelligence analysts?
This one is real and unusually well sourced. Frank Watanabe of the CIA's Directorate of Intelligence wrote "Fifteen Axioms for Intelligence Analysts" in Studies in Intelligence, volume 40 number 5, 1997, setting down the rules he had worked by before leaving on a rotational assignment. The CIA publishes it openly through its Center for the Study of Intelligence, so it can be read in full rather than paraphrased from secondary sources. Its thrust is practical conduct: trust your professional judgement, know what you do not know, and remember that the work exists to serve someone else's decision.
What is the 3x5x2 method of intelligence?
This is a niche term with no widely established definition in competitive intelligence, and the versions circulating do not agree with one another or trace to a common source. If someone in your organisation uses it, ask them which version they mean rather than assuming. For structuring an actual request, the ranked-question approach in this template does the same job with no ambiguity: three to five questions, ordered by how much each moves the decision.
What are the 7 Ps of competitive intelligence?
There is no such framework. The query is reaching for the marketing mix, which is McCarthy's four Ps from 1960, extended to seven for services by Booms and Bitner. Those are tools for planning your own marketing, not for gathering intelligence about a competitor. The pages presenting a seven Ps of competitive intelligence are low-authority content built to capture the query. If you want a real structure for the discipline, the intelligence cycle is the one with genuine institutional history behind it.
What is an example of competitive intelligence?
A concrete one: a competitor's published pricing page shows that view-only seats cost nothing, which explains a pattern of losses in accounts with many read-only stakeholders. That is competitive intelligence, because it is a finding from a legitimate source that changes a decision. Reading the same page and filing it changes nothing and is not. The distinction the discipline turns on is not the sophistication of the source but whether the finding is connected to a decision somebody is about to make.
How do you do competitive intelligence?
Start from a decision rather than from a competitor. Write down what you already believe and how confident you are. Identify which questions are genuinely answerable from public sources, since internal roadmaps, margins and intentions generally are not. Collect from primary sources with dates, keeping observation separate from inference. Deliver something short, addressed to the person making the decision, with confidence levels and an explicit statement of what you could not determine. Then record whether it changed anything, which is the step almost everybody skips.
What are 5 examples of reports a competitive intelligence team produces?
A periodic competitive intelligence report covering what changed in the period. A competitor profile, which is a standing document on one rival. A win/loss report analysing why deals were won and lost. An executive brief, triggered by a single significant event and carrying a recommendation. And a battlecard, which is enablement material rather than a report but is frequently the most-used output. Each has a different audience and cadence, and producing one and circulating it to all five audiences serves none of them.
What is the difference between a request brief and a competitive intelligence report?
One is the input and the other is the output. The request brief is written by the stakeholder before any work happens: the decision, the questions, the constraints, the definition of done. The report is written by the analyst afterwards and contains the findings. They are two ends of the same transaction, and organisations that have only the second half consistently produce reports that are thorough, well sourced and attached to no decision anybody was making.
What should happen when a request has no decision behind it?
Say so and reclassify it rather than refusing it. Some requests genuinely serve standing awareness: onboarding a new executive, a periodic landscape refresh, or monitoring a competitor nobody has met yet. Those are legitimate and should be labelled as awareness work and scheduled against spare capacity. What should not happen is an awareness request being run against a deadline as though it were decision support, which is how intelligence teams end up permanently busy and unable to point at anything they changed.
How long should a competitive intelligence request take?
Most questions worth asking can be answered usefully in one to two working days, and the second day typically adds far less than the first. Anything genuinely requiring a fortnight is a project rather than a request and should be scoped, staffed and scheduled as one. Agree the ceiling in the brief along with what happens if it is exceeded, since the default without that agreement is silence followed by a late delivery, which is the worst available outcome for both sides.
Should the intelligence team ever decline a request?
Yes, and the most common valid reason is that the answer already exists in something the team produced last quarter, which takes minutes to check and to point at. Other legitimate declines: the question cannot be answered from any source available to you, or the decision it supposedly informs has already been taken. A team that accepts everything in arrival order spends its capacity on whoever asks most loudly, which correlates poorly with what matters. Every decline should carry a one-line reason.
What is a competitive intelligence analyst, and what do they earn?
Worth answering briefly since these queries surface alongside template searches, and worth flagging that they are a different intent. A competitive intelligence analyst gathers and interprets information about competitors and markets to support decisions, usually sitting in product marketing or strategy. Salaries vary widely by country, seniority and industry, so any single figure quoted without those qualifiers is close to meaningless. Note also that searches in this area pull in unrelated finance roles, since IB analyst refers to investment banking and has nothing to do with this discipline.
Who should be allowed to submit a competitive intelligence request?
Anyone, with triage doing the filtering rather than the submission process. Restricting who may ask concentrates requests among senior stakeholders, and some of the most valuable questions come from reps who have just lost a deal and noticed something. What matters is that every request goes through the same brief and the same triage, so a well-formed question from a rep outranks a vague one from an executive. That principle only survives if the triage reasons are visible, which is why every verdict carries a written reason.
What is an example of a competitive intelligence request brief?
Request: what exactly do a named competitor's free view-only seats include, and what are the limits? Decision: whether to introduce a free read-only tier of our own, made by the CEO on 31 October before renewals season, with the options being a capped free tier, an uncapped match, or keeping current packaging and retraining on total cost. Questions, ranked: which tiers include free viewer seats and is there a cap; what those seats actually permit beyond viewing; how total cost compares at 40 seats with a 30 to 10 edit-to-view split; and whether the packaging changed recently. Existing beliefs: that the seats are free with no cap, held at low confidence from one second-hand report after a lost deal, and that this decided four of five mid-market losses, held at high confidence from win/loss interviews. Constraints: two working days, no paid sources, public sources only. Triage: accepted narrowed, since three of the four questions were answerable from published pages and the fourth probably was not. Outcome: matching turned out to be a packaging change rather than a repricing, one belief could not be confirmed either way and was reported as undetermined rather than guessed, and the fourth question was dropped on time rather than answered late.
What are the most common mistakes in a competitive intelligence request?
Six recur. Submitting a topic rather than a decision, which produces a document instead of an answer. Asking for something no source could establish, such as a competitor's margins or roadmap. Not writing down what you already believe, so the team spends a day confirming it. Ranking questions by curiosity rather than by decision impact, so the important one goes unanswered. Setting no time ceiling, so the work expands. And never recording whether the answer changed anything, which is why intelligence functions struggle to justify themselves at budget time.
Answer every competitive intelligence request brief faster
Flares keeps competitor data current, so most requests are answered from what is already tracked.
Discover Flares14-day free trial · 30-second setup