How often should you update sales battlecards?

The seven freshness rules

These rules come from our own battlecard method, the one our Battlecard tool runs (read 2026-10-14). The method has eleven steps for building a card. The seven rules below are its freshness rules, in the order they appear in the method.

Demodesk's battlecard guide sets a longer cycle. It gives every card a review every 90 days (read 2026-10-14). Our method does not argue for the number. Our competitor profile method does warn that pricing pages change without announcement. It calls an out-of-date price the claim most likely to be repeated out loud on a live call. In our view, that alone justifies the shorter cycle.

1. Know the three triggers. Refresh a card when it is more than 30 days old. Refresh it when the competitor has launched or changed pricing since the last review. Refresh it too when win-loss findings contradict what the card says.
2. Check the profile's age. A card is built from a competitor profile no older than 30 days, with every claim sourced and dated. If the profile is older, it gets refreshed first.
3. Check what the rival has done since. If they launched, changed pricing or repositioned since the profile, refresh the profile before the card. The method calls a stale card worse than no card, because it is confidently wrong.
4. Hold your own wins to proof again. A win you can no longer prove leaves the card. It moves to "claims cut for lack of proof", with the evidence that would restore it.
5. Re-date every claim about the rival. Each one carries a public source and the date you checked it. Label anything you cannot verify UNVERIFIED, or cut it. When the old source and the new one disagree, ask the user for a ruling and mark the line CONFLICT, ESCALATED with the date.
6. Log the refresh and reset the clock. Add a refresh log line that says what changed, and set the review-by date 30 days out. Someone other than the author reads the card before sellers get it.
7. Sweep every live card once a month. Any card past its review-by date, or whose competitor has moved since, gets flagged as stale. The method never lets a stale card be quietly served.

Worked sample: Asana's ClickUp comparison page, read for freshness

In our view, real battlecards stay inside sales teams, so a vendor's public comparison page is the closest public stand-in for the claims a card draws on. Picture a card against Asana, for any seller whose buyers also weigh Asana. We read Asana's page on ClickUp for the lines such a card would take, and for how long each would stay true. Its trust line and the footnote at the bottom of the page read:

"Asana is trusted by 170,000+ teams*, from startups to Fortune 100 companies"

"*Accurate as of December 2025"

Read on 2026-10-14. Source: Asana vs. ClickUp page. The asterisk after the team count is the only one we found on the page.

Its AI section says:

"Every AI action is visible in your activity log, just like a human teammate—ClickUp attributes agent actions to the user who triggered them, creating accountability blind spots in project history."

Read on 2026-10-14. Source: Asana vs. ClickUp page

What the copy does well. The trust figure carries its own date. That is what rule 5 asks of every line on a card, and a card can copy it with both dates intact. The AI line is specific enough to check: it names a place, the activity log, and a behaviour a buyer can test. The page names its rival in the headline section, so a seller knows exactly which comparison it makes.

What a card could not take as written. On the page, only the team count has an as-of date. The feature table and the claims about ClickUp carry none. In our reading, the AI line is the kind a launch on either side can change. The page's FAQ also says ClickUp does not offer unlimited automation rules. That is a plan limit, and a pricing change is one of the method's triggers. The trust figure is dated December 2025, ten months before our read. So, in our view, a card should carry the page's date and our check date side by side.

The fix: card lines tagged with what would expire them. The method asks for a source and a check date on each line. In our view, one more tag helps: the trigger that would make the line stale. The method does not require it, but it tells the monthly sweep where to look first.

Last reviewed: 2026-10-14   Review by: 2026-11-13 (30 days)
Built from: [competitor profile and date: needs a profile]

## Where they win
- AI actions show in the activity log, like a teammate's,
  per Asana's page. Source: asana.com/compare/asana-vs-clickup,
  checked 2026-10-14. Re-check on: any AI launch.
- Unlimited monthly automation rules and actions on supported
  plans, per the same page.
  Checked 2026-10-14. Re-check on: any pricing or plan change.

## Sources
| Claim | Source | Checked |
| 170,000+ teams | Asana page; its footnote says accurate as of December 2025 | 2026-10-14 |

## Refresh log
- 2026-10-14: created. Each line tagged with the trigger that expires it.

The open "Built from" slot is the point. Under rule 2, these lines wait for a dated profile before a seller sees them.

Common mistakes

• Refreshing the card but not the profile. If the rival moved, the profile goes first. In the method, a card is a rendering of verified research, not a fresh research pass.
• Waiting for the date after a trigger. Under the method, a launch or a pricing change triggers a refresh on its own. The 30-day review-by date is the latest a card can go unreviewed.
• Quietly serving an expired card. The monthly sweep flags it as stale. In our view, sellers should see that flag before they read the card.
• Smoothing over an old source with "reportedly". When the old source and the new one disagree, escalate and mark the line with the date.
• Refreshing without a log line. The log says what changed. In our view, that lets the second reader check only the change.

Questions people ask

How fast should battlecards be updated?

In our method, no live card goes more than 30 days without a review. A trigger cuts that short: the competitor launches, changes pricing or repositions, or win-loss findings contradict the card. Then the profile is refreshed first and the card second. Demodesk's guide uses a longer cycle: 90 days. In our view, 30 is safer, because pricing pages change without announcement.

How do you keep your battlecards up to date?

Give every card a review-by date 30 days out and run one sweep a month across all live cards. Flag anything past its date, or whose rival has moved, as stale. Each refresh re-dates every rival claim and adds a refresh log line. Someone other than the author reads it before sellers do. Our battlecard template has the header and log slots built in.

Sources

• Asana vs. ClickUp page, Asana, https://asana.com/compare/asana-vs-clickup, read 2026-10-14
• Battle-Tested Guide: How Top Sales Teams Create Winning Battlecards, Demodesk, https://demodesk.ai/blog/create-winning-battlecards (redirected from demodesk.com), read 2026-10-14
• Google results for "how often should you update sales battlecards" (People also ask, and two r/ProductMarketing thread titles, "How fast should the battlecards be updated?" and "How do you keep your battlecards up-to-date without ..."; we did not open the threads because Reddit blocks logged-out fetches), https://www.google.com/search?q=how+often+should+you+update+sales+battlecards, read 2026-10-14
• Our battlecard and competitor profile method skills, as run by the Battlecard tool (ours, read 2026-10-14)