| Category | Stated objection (examples) | Likely root concern | What the customer needs to hear first | Response approach |
|---|---|---|---|---|
| Cost | "Cloud is more expensive." / "The TCO doesn't work." / "We can't afford this." | Variable cost feels uncontrollable vs. predictable capital. Hidden costs in Azure they can't yet see. Budget approval risk. | "Your concern about cost predictability is completely valid, and it's the most common thing we get wrong in our first TCO comparison." | Run a symmetric TCO (M02). Show Reserved Instance pricing. Show Azure Cost Management. Address budget mechanism, not total cost. |
| Risk | "We can't move critical workloads to the cloud." / "What if it goes down?" / "Our data can't leave our data center." | Fear of career risk from a public failure. Past outage or data loss incident. Regulatory interpretation uncertainty. | "It sounds like you've been through a situation where something like this went wrong, or you're accountable for one going wrong, and I want to take that seriously." | Reference customer in same industry/regulatory context. Show compliance certifications. Propose a low-risk proof of value first. |
| Trust | "We've worked with [other vendor] before and it didn't go well." / "We need to see this work somewhere first." / "How do we know Microsoft won't change this?" | Prior vendor burn. Skepticism about longevity of platform commitment. Discomfort with the individual CSA, not the technology. | "That's a completely fair position, and I'd rather earn your trust with evidence than ask you to take it on faith." | Reference architecture and customer. Executive sponsor bridge. Proof-of-value with defined criteria. Service SLA and support commitment in writing. |
| Technical Doubt | "I don't think Azure can do [X]." / "Our workload is too complex for PaaS." / "The latency won't meet our SLA." | Valid technical gap. Lack of access to the right technical depth. Engineering team's preference for the known (on-prem tooling). | "Let's test that specifically: I'd rather surface a real limitation now than design around one later." | Proof of concept. Reference architecture with benchmark data. Technical deep-dive with engineering team. Azure engineering escalation if needed. |
| Political | "We need to involve [person] before we can decide." / "The team isn't aligned yet." / "There are other stakeholders we need to consult." | A shadow stakeholder has been surfaced. The sponsor doesn't have authority they implied they had. Internal political opposition the sponsor can't resolve alone. | "That makes complete sense: let's make sure we have the right people in the room. Who would need to be part of this conversation?" | Return to Shadow Stakeholder Map (M01). Apply Triangulation (M04). Design Executive Pivot if appropriate (M04). |
| Momentum / Inertia | "We're not ready for this yet." / "Let's revisit in Q3." / "We have too much going on right now." | Fear of change more than objection to the solution. Capacity constraint is real. No urgency because Cost of Inaction has not landed. | "What would need to be true for the timing to feel right? I want to understand what's competing for attention right now." | Deploy Cost of Inaction (M02). Propose a minimal Phase 1 that fits current capacity. Surface and name the real competing priority. |
Label → Pause → Mirror → Acknowledge → Address.
Every objection response follows this sequence. Skipping the Label and Pause produces a rebuttal. Following the sequence produces a conversation. The difference between a sale and an argument is usually steps 1 and 2.