> ## Documentation Index
> Fetch the complete documentation index at: https://docs.snowdoughnut.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Competitor battle card
> A fill-in workbook for a single competitor: how they position themselves, where they genuinely win, where we win, the objections that come with them, and the questions that expose their limits. Fill one in per competitor and file the row in the battle card library.
*Fill in this workbook as you go. Each section has a "Concept review" dropdown underneath it. These explain the concept behind the section, not a rule to follow. Your market might work differently than the examples show, and that's fine.*
*Examples throughout use Doughnut Labs, a SaaS company that sells disruptive Doughnut Technology, against two invented competitors: Cruller Systems, a large enterprise platform, and Glazeworks, a cheap single-purpose tool. Delete the grayed example text as you fill each section in.*
One card per competitor. Before starting a new one, check the [battle card library](/battle-card-library) for an existing card and confirm the competitor is worth maintaining a card for. A card nobody owns goes stale within a quarter and costs more credibility than it ever returns.
Section 6 only if you have real pricing. Section 7 is assembled from everything above it.
Each line should trace back to a won or lost deal, a recorded call, or a published page you read on a date you can name. Delete anything that traces only to what the team believes.
If a line can't be spoken in a sentence on a call, it belongs in a research doc rather than here.
Add the card to the [battle card library](/battle-card-library) with its tier, owner, and next review date.
***
## Card header
| Field | Fill in |
| :------------------------------- | :------------------------------------------------------------------------------ |
| Competitor | *E.g. Cruller Systems* |
| Tier | *E.g. Tier 1* |
| [Owner](/glossary#owner) | *E.g. Priya Nadel* |
| Last reviewed | *E.g. 12 Aug 2026* |
| Review date | *E.g. 12 Nov 2026* |
| Deals seen in, last two quarters | *E.g. 23* |
| Sources used | *E.g. 6 loss interviews, 4 recorded calls, their pricing page read 10 Aug 2026* |
The header exists so a reader can decide how much weight to put on the page before reading it. A card built from twenty recent deals and a card built from one conversation and a website read the same once the header is missing.
The deal count is doing quiet work beyond credibility. A competitor whose count is falling quarter on quarter may not warrant a maintained card at all, and the header is where that shows up before someone spends another afternoon updating it.
Review dates get set at different intervals in different markets. A category where products ship monthly makes a six month old claim risky, while a slower category can hold a card for a year without much drift. What tends to cause trouble is a card with no date on it, because nothing then distinguishes a page checked last week from one nobody has opened since it was written.
## 1. Competitor overview
**Company name, and any product names a buyer would say out loud:**
*E.g. Cruller Systems. Buyers usually say "Cruller" and sometimes name the module, "Cruller Flow".*
**How do they position themselves? Their claim, in their words, not ours:**
*E.g. "The enterprise platform for regulated operations." They lead on governance, audit trails, and configurability, and pitch to a buyer who has been told to consolidate tools.*
**Who do they primarily sell to? Company type, team, and the role that signs:**
*E.g. Companies over 1,000 people in financial services and healthcare. They sell to a VP of Operations, and the signature comes from IT or procurement after a security review.*
**Where do we overlap, and where do we not compete at all?**
*E.g. We overlap on process operations teams at 200 to 1,000 people. Below 200 people we rarely see them. In regulated enterprise above 5,000 we are not in the deal.*
A competitor's positioning stated in their own words reads differently than our summary of it, and the gap between the two is where trouble starts. A rep who has only seen our version gets caught out in a call by a buyer repeating the real one, and being caught out reads as not knowing the market.
The overlap question is what turns this section into something usable. Two companies can share a category and compete for almost no deals, or share nothing on paper and compete for every one. Where the overlap actually sits is often narrower than either company's marketing suggests, and knowing the edge of it is what lets a rep tell early whether this deal is one of the contested ones.
Who signs matters as much as who uses. A product bought by an operations lead and a product bought after a procurement cycle run on different timelines and get evaluated on different criteria, even when the two products do similar things.
## 2. Why they win
**Where do they genuinely beat us? One row per reason, with the deal situation it shows up in.**
| Their strength | The deal situation where it decides | How often we see it |
| :-------------------------------------------------------------------------- | :---------------------------------------------------------------------- | :---------------------------- |
| *E.g. SOC 2 Type II, HIPAA, and a completed security questionnaire library* | *E.g. Any deal where IT runs a formal security review before a pilot* | *E.g. Most regulated deals* |
| *E.g. 40 native integrations including two legacy systems we don't support* | *E.g. Buyer has an existing warehouse contract and wants no middleware* | *E.g. Occasional* |
| *E.g. Named implementation manager included above their mid tier* | *E.g. Buyer has no internal owner for the rollout* | *E.g. Common in larger deals* |
| \[add strength] | | |
**What do buyers believe about them, whether or not it's accurate?**
*E.g. "Nobody gets fired for buying Cruller." Buyers assume enterprise-grade means safe, and assume a smaller vendor means risk, before either has been tested.*
**Which deals should we qualify out of because of the above?**
*E.g. Deals where a SOC 2 Type II report is a gating requirement before a pilot can start. We lose these late and expensively, and the honest answer is to say so in week one.*
This section is the one that decides whether the rest of the card gets believed. A rep who has lost three deals to a competitor and then reads a page listing only that competitor's weaknesses concludes the page was written by someone who has not been in the room.
There is a second use that has nothing to do with credibility. Every reason a competitor wins is also a qualification rule, and qualification rules are worth more early than late. A deal that was never winnable costs the same amount of work as one that was, and the difference between finding out in week one and week nine is most of a quarter.
Buyer perception belongs here alongside fact, and the two are worth keeping separate on the page. A belief that a competitor is safer is not a feature and still loses deals, and it gets handled by evidence rather than by argument, which makes it a different problem than a genuine capability gap.
## 3. Why we win against them
**Where do we beat them? One row per reason, with the evidence behind it.**
| Our advantage | The gap it addresses | Evidence |
| :------------------------------------------------------------------- | :-------------------------------------------------------------- | :---------------------------------------------------------------- |
| *E.g. Live in an afternoon by the process owner* | *E.g. Their median implementation runs 11 weeks with a partner* | *E.g. 9 of our last 12 accounts were in production inside 5 days* |
| *E.g. One workspace for the process and the documentation around it* | *E.g. Their wiki is a separate product on a separate contract* | *E.g. Named in 4 of 6 recent switch interviews* |
| *E.g. Per-workspace pricing, no per-seat charge for viewers* | *E.g. Their viewer seats bill at 60% of a full seat* | *E.g. Modelled on their published price list, read 10 Aug 2026* |
| \[add advantage] | | |
**What do their customers complain about, in their words?**
*E.g. "Every change goes through a Cruller consultant." The complaint is about needing a paid third party for routine configuration, and it shows up in review sites and in every switch interview we've run.*
**Proof points from customers who switched. One row per story you're cleared to use.**
| Customer | What they left | The reason they gave | Cleared for use |
| :------------------------------------ | :--------------------- | :------------------------------------------------------------------ | :------------------------------------- |
| *E.g. Northgate Logistics* | *E.g. Cruller Systems* | *E.g. "We were paying for configurability we needed twice a year."* | *E.g. Yes, named, approved 3 Jul 2026* |
| *E.g. Anonymous, 400-person retailer* | *E.g. Glazeworks* | *E.g. Outgrew a single-purpose tool and didn't want a second one* | *E.g. Unnamed only* |
| \[add proof point] | | | |
The strength of this section comes from the evidence column rather than the claim column. "Faster to set up" is a claim any vendor in any category can make and a buyer has heard from all of them. A median time to production, taken from named accounts, is a different kind of statement, and it survives a buyer pushing back.
Complaints in the customer's own words carry further than a feature gap described in ours. A buyer weighing two vendors discounts what either says about the other, and largely does not discount what a peer said about living with the product for a year.
Switch stories carry a clearance question that has nothing to do with how good the story is. Whether a customer can be named, in what context, and whether the quote was approved for external use are separate permissions from whether the story is true. Which of those apply is worth recording next to the story, because the moment someone needs it is the moment they are least likely to go and check.
## 4. Common objections and how to handle them
**The objections that come up when this competitor is in the deal. Three to five, in the order you hear them.**
| Objection, as the buyer says it | What's true in it | The response |
| :--------------------------------------------------------------------------- | :------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| *E.g. "Cruller has more integrations."* | *E.g. They do. 40 native to our 18.* | *E.g. Agree on the count, then ask which ones they actually run. Most buyers name four, and we support all four natively.* |
| *E.g. "You're a smaller company. What if you're not around in three years?"* | *E.g. Fair question about a genuine risk.* | *E.g. Name the funding position and the customer count, then offer data export terms in writing. The buyer is asking about lock-in, so answer the lock-in question.* |
| *E.g. "We need a formal security review before any pilot."* | *E.g. They have the completed questionnaire library and we do not.* | *E.g. Confirm what we hold today and the date the next certification lands. If it gates the pilot, qualify out rather than stalling in it.* |
| \[add objection] | | |
Most objections that reach a card contain something accurate. A response that denies the accurate part is arguing with a buyer about a fact they can check, and the rest of the call is spent recovering from it.
Conceding the true part first tends to change what the conversation is about. Agreeing that a competitor has more integrations moves the discussion from the count to which integrations this buyer runs, which is the ground where the decision actually gets made, and it gets there without anyone being told they are wrong.
Some objections are questions wearing a statement's clothes. A buyer raising company size is often asking what happens to their data if the vendor disappears, and answering the size question leaves the real one sitting there. Working out which underlying question an objection is standing in for is usually what separates a response that lands from one that is technically correct.
Length is its own consideration. A working set of three to five is what gets scanned before a call. A list of twelve is a research document, and the entries at the bottom get read by nobody.
## 5. Landmine questions
**Questions to ask the buyer that surface this competitor's limits, in their words rather than ours. Three to five.**
| Question to ask | The limitation it surfaces | What a concerning answer sounds like |
| :--------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------- | :----------------------------------------------------------------------------- |
| *E.g. "Who makes a change to the process once it's live, and how long does that take?"* | *E.g. Configuration runs through a paid Cruller consultant* | *E.g. "We'd raise a ticket with our implementation partner."* |
| *E.g. "How many people need to read the process versus edit it, and what does a read-only seat cost you today?"* | *E.g. Viewer seats billed at 60% of a full seat* | *E.g. "Everyone in ops has a full licence because there's no cheaper option."* |
| *E.g. "Where does the documentation for this process live, and who keeps it current?"* | *E.g. Their wiki is a separate product on a separate contract* | *E.g. "In a different system, and it's usually out of date."* |
| \[add question] | | |
The mechanism is that the buyer supplies the answer. A vendor stating a competitor limitation is making a claim the buyer discounts by default. A buyer describing the same limitation while answering a question has reached the conclusion themselves, and people rarely argue with their own conclusions.
Timing carries most of the effect. These questions do their work early, while the buyer is still deciding what to evaluate on. Asked after a scorecard exists, the same question is a challenge to criteria the buyer has already committed to, which is a much harder conversation.
Two things blunt a question. One so obviously leading that it reads as a script gets recognized, and the recognition costs credibility for everything that follows. One aimed at a limitation this buyer genuinely does not care about spends a good moment on a weakness that was never going to decide the deal, which is why the limitation being real is not on its own enough to make the question worth asking.
## 6. Pricing and packaging comparison
Optional: fill in only where you have published prices or figures from a deal you can cite. Note the date you read them.
**How their pricing is structured, and where ours differs:**
| Dimension | Them | Us |
| :--------------- | :------------------------------------------- | :-------------------------------------- |
| Pricing model | *E.g. Per seat, annual commitment* | *E.g. Per workspace, monthly or annual* |
| Entry price | *E.g. \$18,000 a year, 25 seat minimum* | *E.g. \$4,800 a year, no seat minimum* |
| Read-only access | *E.g. 60% of a full seat* | *E.g. Included* |
| Implementation | *E.g. $15,000 to $40,000, partner-delivered* | *E.g. None* |
| Contract term | *E.g. 24 months standard* | *E.g. 12 months, monthly available* |
| \[add dimension] | | |
**Costs a buyer usually discovers after signing:**
*E.g. Configuration changes billed at a day rate after the first 90 days. Sandbox environments charged separately. Above 100 seats their price moves to a custom quote that has come in 30% above list in the two deals we've seen.*
**Total cost over three years, on a realistic configuration. State the assumptions.**
*E.g. 60 users, 20 of them read-only, one integration. Cruller Systems: roughly $186,000 including implementation. Doughnut Labs: roughly $31,000. Assumes their list pricing read 10 Aug 2026 and no negotiated discount.*
Published prices and paid prices diverge in most enterprise categories, sometimes by a wide margin. A comparison built on list pricing is still worth having, and it is worth labelling as list pricing, because a buyer holding a discounted quote will notice the difference and will trust the whole page less if the page pretended otherwise.
Where a real gap tends to live is in the shape of the model rather than the headline number. Per-seat and per-workspace pricing produce very different curves as a team grows, and the crossover point is a concrete thing a buyer can be walked through. Two products can look similarly priced at 20 users and differ by an order of magnitude at 200.
Three year totals invite an assumption question, since almost every input can be chosen to favour whoever is doing the modelling. Writing the assumptions next to the number is what makes it defensible when a buyer runs their own version and gets something different.
## 7. Key takeaways and sales strategy
**The strategy against this competitor, in two or three sentences:**
*E.g. Compete on time to value and on who controls change after launch. Avoid a feature-count comparison, which we lose. Get the process owner into a working setup before IT builds a formal scorecard, because a running workflow reframes the evaluation.*
**Soundbites a rep can say as written. Two or three.**
* *E.g. "They're built for a team that has a consultant on retainer. We're built for the person who owns the process."*
* *E.g. "Same problem, different bet. They bet on configurability, we bet on you never needing a ticket to change something."*
* *E.g. "Most teams we talk to were paying for depth they used twice a year."*
**Stories and use cases that fit deals against this competitor:**
*E.g. Northgate Logistics, who ran a 6 week Cruller pilot before switching and were in production with us in 4 days. Cleared to name, approved 3 Jul 2026.*
**What we do not say about this competitor:**
*E.g. Anything about their outage in March. It's public, it's true, and it reads as a smear in a call. Nothing about their pricing that isn't from their published page.*
A strategy differs from a summary in that it names something to avoid. "Compete on time to value" is guidance only when it sits next to "do not compete on integration count," because the second half is what tells a rep which ground to leave alone.
Soundbites are written to be said rather than read, which is a real constraint on the phrasing. A line that scans on a page and comes out clumsy in a sentence gets silently rewritten in the moment by every rep who uses it, which is how a card's language drifts away from the approved wording nobody meant to abandon.
The last prompt saves more deals than it looks like it should. Competitive conversations can slide into attacks that feel effective and land badly, and buyers tend to read a vendor criticizing a rival as a vendor who is worried. Deciding in advance which true things stay unsaid keeps that out of live calls.
***
## Before you publish the card
Anything traceable only to team belief comes off the page.
Rewrite every "they can't" as what is actually true today: slowly, partially, or only on their top tier.
Named customers, quotes, and figures each carry their own permission. See the [legal review process](/legal-review-process).
Anything you stumble over is a line that will be rewritten mid-call by whoever uses it.
Add the card to the [battle card library](/battle-card-library) with its tier, owner, and review date.
## Related resources
* [**Battle card concepts**](/battle-card-concepts) What a card is for, and why it is structured this way.
* [**Battle card library**](/battle-card-library) Every card in circulation, with tier, owner, and review date.
* [**Positioning**](/positioning) The competitive frame this card operates inside.
* [**Messaging**](/messaging) The approved words and the claims that have been cleared.
* [**Legal review process**](/legal-review-process) What comparative claims need before they leave a sales conversation.