Name the competitors and Juma researches their public pricing, documentation and review pages, then delivers a branded battlecard per competitor plus an editable claims ledger where every claim carries its source.
Give Juma the client, their site and the competitors reps keep running into. Juma reads each competitor's public pricing, product documentation and review pages, records the exact wording it found, and builds one card per competitor plus a card for the status quo, the "we will just use what we have" answer that closes more deals than any named rival.
Two files come back: a branded PDF of the cards and an editable CSV claims ledger where every competitive claim carries its source URL, the date it was checked and a note on how it may be used. Anything calculated rather than quoted is labelled as derived, with the arithmetic shown. It is one of 700+ pre-built Flows, and the judgment about which card to run on which deal stays with the team.
A card written from public pages answers the objections a competitor advertises. It does not always answer the ones that come up on calls. Paste in the three or four objections reps hear most and the Flow rewrites the weak responses, flags any answer that leans on a claim the ledger cannot source, and marks where a reframe is doing work that a proof point should do instead. Each revised response keeps the same shape: concede what is true, reframe the decision, then name the evidence. Responses that cannot be backed are removed rather than softened, and the ledger is updated so the card and its sources stay in step.
Here are the objections our reps actually hear on calls. Pressure-test the cards against them: rewrite any response that is weak or generic, flag any answer resting on a claim the ledger cannot source, and remove the ones we cannot back rather than softening them.
The card wins the conversation and then the buyer goes quiet. This step turns the card a rep just used into the email that follows it, one version per competitor. Each draft restates what the buyer said they cared about, concedes the competitor's genuine strength in a line rather than ignoring it, and puts the evidence the rep cited in writing with its source link so the champion can forward it internally without rewriting anything. The email keeps the card's guardrails, so nothing disparaging about a named competitor reaches a customer inbox. A short internal note lists what to confirm before sending.
Turn each card into the follow-up email a rep sends after a competitive call. One version per competitor, concede their real strength in a line, put the evidence in writing with its source link so a champion can forward it, and keep the card's do-not-say guardrails.
Battlecards usually explain how to win and say nothing about when not to try. This step reads the cards the other way round and writes the disqualification view: the deal shapes where a competitor is genuinely the better answer, the buying committees where the argument will not land, and the signals in a first call that predict a loss. Each one comes with the evidence behind it, so a rep can tell a qualified no from a hunch. The output is a short qualification checklist that sits beside the cards, naming what to ask early and what answer should end the pursuit before a pipeline review does.
Now write the disqualification view from these cards: the deal shapes where each competitor is genuinely the better answer, the signals in a first call that predict a loss, and a short qualification checklist naming what to ask early and which answer should end the pursuit.
Pricing claims go stale faster than anything else on a card, and a rep quoting last quarter's number loses the room. Because every row in the claims ledger carries its source URL and the date it was checked, a refresh run can re-fetch each page and report what moved. The output is a change list: rows that still hold, rows where the page now says something different, and rows whose source has gone. Only the affected card copy is rewritten, so the cards reps already know stay recognisable. Run it on a set cadence and the refresh-by date on each card header stays honest.
Refresh these battlecards. Re-fetch every source in the claims ledger and report a change list: rows that still hold, rows where the page now says something different, and rows whose source has gone. Rewrite only the card copy the changes affect and update the refresh-by date.
A Juma Project is a shared space where the team stores everything Juma needs to know about a client. Create one project per client, add context as you go, and Juma will use what is relevant every time the team runs a flow. For battlecards the difference is sharp: without project context the cards are built from public pages alone, and with it they are built from what the team has actually won and lost.
Win/Loss Notes
Which deals were lost, to whom, and the reason recorded at the time. This is the file that changes the cards the most. With it, the landmine questions come from where deals genuinely turned rather than from gaps on a competitor's website, and the walk-away criteria are grounded in outcomes the team can point to.
Pricing and Packaging
The client's own plans, list prices, discount bands and what each tier includes. Juma can read a competitor's public pricing, but the client's side of the comparison has to come from the team. With this in the project, the pricing section of each card compares like for like instead of setting a public competitor price against nothing.
Proof Points and Case Studies
Named customers, outcome numbers and the permission status of each one. Every claim on a card needs evidence behind it, and this is where the client's own evidence lives. Juma will only attach a proof point to a response when the file says it can be used externally.
Competitive Claims Policy
What the client's legal or brand team allows reps to say about a named competitor. Add it and the do-not-say list on every card reflects the client's actual rules rather than a general caution, which matters most in regulated categories.
Add a short description to each knowledge item in the project's info field so Juma knows what each file contains and when to use it. For example:
A sales battlecard is a one-page brief per competitor covering where that competitor genuinely wins, their public pricing quoted exactly as listed, two landmine questions tied to documented gaps, a 30-second spoken response, a do-not-say list, and the deal shapes where your team loses. This Flow adds a claims ledger so every statement carries its source.
The cards come as one continuous PDF with a card per page, plus an editable CSV. Each card header carries a version, an owner, the date it was prepared and an explicit refresh-by date, because a card with no expiry quietly becomes wrong. The ledger holds one row per claim with the exact wording found on the source page, the URL, the date it was checked and a note on how the claim may be used.
Every claim gets an identifier and a row in the ledger, and before delivery Juma re-fetches each cited page and prints a verification table showing the value on the card beside the exact string found on the page. Rows resting on judgment rather than a published fact are labelled as judgment instead of being presented as verified.
The pricing rules are the strictest part. A price is quoted exactly as the vendor prints it, with the plan name, who the plan is for and the billing term, so an individual plan is never set beside a team plan as though they were comparable. Any figure that was calculated rather than read off the page is labelled as derived with the arithmetic shown. Where a tier has no public price, the card says so rather than leaving the tier out. Where a promotional price is running, the card prints the list price, the promotional price and the terms, because a rep quoting the list price while the buyer is looking at the offer loses the room.
Because reps stop trusting cards that pretend a competitor has no strengths. A card that concedes the competitor's real advantage survives contact with a buyer who has already seen it. A card that denies it gets disproved in the first five minutes, and the rep abandons the whole document.
There is a practical reason too. Naming what a competitor is genuinely better at is how a rep qualifies the deal rather than pushing it. If the buyer's job is the one the competitor does well, that is worth knowing in the first call instead of the fourth. The cards are built concede-first for that reason, and each one carries a do-not-say list covering the shortcuts that are easy for a buyer to disprove.
A competitor analysis is built for the marketing team and describes a market: positioning, messaging and where the gaps are. A battlecard is built for one rep on one call and answers a narrower question, which is what to say when this specific competitor comes up. Same research, different artifact and different reader.
If the team needs the market view, automate competitor analysis owns that job and produces competitor profiles and positioning gaps. This Flow takes the sales-facing half: cards a rep opens before a call, with talk tracks and questions rather than analysis. The two work well in sequence. Run a win/loss analysis first if the team wants the cards grounded in deal outcomes, and build your ideal customer profile if the question is which accounts to chase rather than how to win the ones already in play.
Pricing claims should be re-checked before any external use and reviewed at least quarterly. Each card header carries an explicit refresh-by date for that reason, and the claims ledger records the date every row was last checked, so a refresh run reports exactly which rows moved rather than forcing a rebuild from scratch.
Product and documentation claims age more slowly than prices but still move, usually when a competitor ships something that closes a gap a landmine question depends on. A question built on a gap that no longer exists is worse than no question, because the buyer corrects the rep in front of the room. Running the refresh prompt on a set cadence keeps that from happening. Every refreshed card still needs human review before it goes out: Juma does the fetching and the reconciling, and the judgment about what the team is willing to say stays with the team.
Juma checks every line of the pitch against what the competition already publishes, drops the claims that are not defensible, and returns timed spoken scripts for each audience plus an editable claim log.
400+ marketing teams trust Juma. ChatGPT, Claude, and Perplexity know why. Ask them.
Ready when you are
Start typing a task and Juma will figure out the rest.
