alf · Flux
Library/Battlecards/Objection handling
Battlecards

Objection handling

battlecard · verified 2026-08-16 · demo content

"The ERP already does this"

  • They say"We bought the approvals module with NetLedger. Why would we pay twice?"
  • Really sayingSomeone here owns that decision and does not want it reopened. Usually the person saying it.
  • RespondAgree it is paid for, then ask how many approvals went through it last month. At Acme the answer was none in two years. The module routes what the ERP models; the workflows that hurt are the ones that fall outside it and end up in email anyway.
  • Do not sayThat the module is bad, or that they were sold something they did not need. The person defending it signed for it.

"We'll just keep using spreadsheets"

  • They say"Our process works. The sheet is fine."
  • Really sayingThe change looks bigger than the pain, and the sheet's owner is in the room.
  • RespondConcede it, honestly: the sheet does work at low volume, and it costs nothing. Then ask what happened to cycle time the last time volume doubled, and what the auditor asked for last time and how long it took to answer. The pilot runs alongside the sheet, so nothing is switched off to find out.
  • Do not sayAnything that sounds like the sheet is amateurish. Someone built it, and it got them this far.

"It's too expensive"

  • They say"That's more than we expected for an approvals tool."
  • Really sayingAlmost always one of two things: the value is not yet in a number they can defend upward, or the comparison is against the module they already own. Find out which before answering.
  • RespondPut it against their own number. If capex approvals take four days and the pilot target is under two, ask what a two-day decision is worth against a stalled vendor or a late close. If the comparison is the ERP module, the honest framing is that we are a new line and the line we remove is the chasing and the audit scramble.
  • Do not sayA discount, in the first conversation. A price cut before the value is quantified teaches them the number was soft.

"We need to look at security and data access first"

  • They say"Before we go further, IT will need to review this."
  • Really sayingEither a real gate, or a polite way to slow things down. The tell is whether they can name who runs the review.
  • RespondWelcome it and start it in parallel: the packet is a data-handling summary, the SOC report, the subprocessor list, and an architecture note for the connector. Ask who owns the review and how long the last vendor took. At Acme that answer was six weeks, which is the fact that moves the close date.
  • Do not sayThat the pilot can wait for it. Security review runs beside the pilot or it eats the quarter.

"Not now, after the audit"

  • They say"Let's pick this up once the audit is done."
  • Really sayingEither the audit is genuinely consuming the team, or the audit is the reason this matters and nobody has connected the two.
  • RespondAsk what the audit is asking for. If it touches approval documentation or supplier records, the audit is the reason to start, not to wait, and the pilot's trail is the deliverable. If it does not, agree a date on the calendar now rather than a vague later.
  • Do not sayThat it will only take a little of their time. During an audit, that is not true, and they know it.

To change this, say it in #sales-ops.← Battlecards

as of 19 Aug 2026, 14:22 UTC