You confirm it landed — and then you re-close. The most common leak in objection handling isn't the response; it's the rep answering well and then drifting onward as if resolution happened by itself. The framework's logic demands a check: is that concern actually settled? Because an objection answered but not confirmed is still standing when the decision gets made.
The short answer
The confirmation is a question, not a hope — the same tie-down discipline the presentation runs on, aimed at the concern you just addressed. A genuine resolution changes the room: the topic closes, the energy returns to the project. A performed resolution — the polite nod that means I'm done discussing this, not convinced by it — is information too: the objection wasn't the real one, or the answer didn't reach it, and the framework sends you back to diagnosis rather than forward to hope.
Then re-close. Ground cleared by an answered objection is the most perishable asset in the appointment; the system has a re-close discipline precisely because the moment after a resolved objection is when decisions get made — or get postponed while the rep admires his answer.
How it runs
The framework predicts the loop: answering creates the opening for the next objection. That's not failure — handled one at a time, isolated each time, a second objection is just the next layer of the same decision. It only becomes the death spiral when the rep starts answering randomly, stacking responses without diagnosis. Confirm, re-close, and if another objection stands up, run the framework again — slower than the ping-pong, faster than losing.
Every moment in these guides is a Spar round you can lose safely tonight instead of at a kitchen table tomorrow. Round 1 is free; the full camp is $29/month. Spar before you knock.