Sales Objection Handling Script

The eight objections your reps actually hear, each with the real question underneath it, a response that does not sound scripted, the proof to ask for, and the trap to avoid — built from your offer, price point and competitive set.

A Markdown objection script containing: (1) exactly eight objections, each with the prospect's actual wording, the underlying concern, a two-to-four-sentence response, a follow-up question, and the common rep mistake; (2) coverage of price, timing, status quo, a competitor, build-in-house, security or procurement, no champion and no pain; (3) [VERIFY] tags on any claim about a named competitor; (4) a closing 'These are disqualifiers, not objections' section naming two or three walk-away cases.

# Objection script — incident response, $18/responder

### 1. Price — "That is more than we pay now."
**Underneath:** they are comparing your list price to their renewal price, not to the alternative.
**Response:** That is fair, and I am not going to argue you into a bigger number. The comparison I would make is not seat price against seat price, it is what the post-incident half costs you today — the hours someone spends rebuilding a timeline and writing the retro. If that is under an hour a month across the team, we are genuinely more expensive.
**Ask back:** Roughly how long does a retro take your team from incident close to a document someone would read?
**Rep mistake:** discounting inside the first call. You have not established the comparison yet, so the discount just confirms the list price was fiction.

### 2. Timing — "Revisit next quarter."
**Underneath:** there is no forcing event, or there is one and you have not found it.
**Response:** Happy to. Before I put a note in the calendar, is next quarter better because of budget, because of a migration, or because right now is genuinely on fire? Those three lead to very different conversations and I would rather have the right one.
**Ask back:** What has to be true in Q3 that is not true today?
**Rep mistake:** accepting the date and disappearing. A deferral with no named trigger is a soft no wearing a calendar invite.

### 3. Status quo — "On-call works fine as it is."
**Underneath:** the pain is distributed across people who are not in this meeting.
**Response:** Then I would leave paging alone. The teams that switch usually do not switch because paging broke — they switch because the incident ended and nobody could reconstruct what happened in the first eleven minutes. If your timelines are already clean, that is a genuine reason not to move.
**Ask back:** After the last severity-one, how long did it take to agree on the timeline?
**Rep mistake:** listing features against a system the buyer is not unhappy with.

### 4. Competitor — "We already use PagerDuty."
**Underneath:** switching cost, not product preference.
**Response:** Most of our customers did too, and a good number still run it for paging. Where teams tend to find us better is everything after the page — timeline capture and the retro draft. [VERIFY: PagerDuty's current post-incident and retro capabilities have changed across releases; confirm the specific gap before claiming it on a call.] The honest version is that if paging depth is the whole job, staying put is reasonable.
**Ask back:** Is the pain in getting the right person awake, or in what happens after they are?
**Rep mistake:** rubbishing the incumbent. The buyer chose it, so the criticism lands on them.

### 5. Build in-house — "We have a Slack bot that does this."
**Underneath:** an engineer owns it and is in the room, or will hear about this meeting.
**Response:** Those bots are usually good, and I would not replace one that works. The question I would ask is who is on the hook when it breaks at 3am during the incident it is supposed to be helping with, and whether that person wants the job. That is normally the deciding factor rather than features.
**Ask back:** If the person who wrote it left tomorrow, what happens?
**Rep mistake:** implying the internal tool is bad in front of the person who wrote it.

### 6. Security and procurement — "You will not pass our review."
**Underneath:** they have been burned by a vendor who wasted a quarter.
**Response:** Possibly not, and it is cheaper for both of us to find that out now. The place we most often fail is enterprise SSO depth, so if your review has hard requirements there, tell me and I will say straight away whether we meet them.
**Ask back:** Can you send the requirements list before we go further?
**Rep mistake:** promising a roadmap item to clear a gate. It converts a lost deal into a lost deal plus a broken relationship.

### 7. No champion — "I will share this with the team."
**Underneath:** they are not the buyer and are not willing to say so.
**Response:** That is useful — what usually helps is knowing who on the team feels this most. If it is the SRE lead who ran the last big incident, I would rather send something written for them than a generic deck for everyone.
**Ask back:** Who ran the last severity-one, and would they be worth including?
**Rep mistake:** sending a deck and calling it progress.

### 8. No pain — "We have not had a bad incident in a year."
**Underneath:** genuinely low urgency, and possibly a genuinely good answer.
**Response:** Then I would not move now. The one thing I would flag is that the teams who get hurt most are the ones whose last painful incident is far enough back that the process quietly rotted. Worth a check rather than a purchase.
**Ask back:** When was the last time you ran a game day?
**Rep mistake:** manufacturing urgency. This buyer talks to peers and the reputation cost outlives the quarter.

## These are disqualifiers, not objections
- **Hard enterprise SSO requirements in the security review.** The notes say this is a known weakness. Walk, and say why — you will be invited back when it ships.
- **Under about 15 responders.** At $18 a seat the deal does not carry the implementation effort, and a small unhappy account costs more in support than it earns.
- **No named owner of post-incident process anywhere in the organisation.** With no owner there is no one for the second half of the product to land on, and the renewal will fail even if the deal closes.