Customer-safe claims and escalation

The customer problem

The fastest way to lose an enterprise customer is to be caught having said something that was not true - not through dishonesty, but through confident over-claiming. A seller promises an integration, a security property, a saving, or an entitlement; it turns out to need work, or caveats, or was never real; and from that moment every other claim is discounted. In regulated and procurement-heavy industries - BFSI, large RCM, GCC - this is fatal, because the customer's own risk and security people are specifically looking for the gap between what was sold and what is true. The business impact of one over-claim is disproportionate: stalled security review, a poisoned implementation, a renewal lost to 'they told us X and it was not true.' The discipline that prevents all of it is cheap and learnable: know which tier your claim is in, and escalate the rest.

The three tiers of claim

Sort every statement before you make it:

1. Verified fact - something you can stand behind because product or a specialist has confirmed it, or it is approved collateral. Say it plainly.
2. Demo-shown behaviour - something the live lab demonstrates about how the product works and is shaped (the staircase, each app's question, that capture is policy-driven, that Value Leakage separates capacity from cash). Say it as 'here is how the product does this,' and never let a demo number stand as a customer result or benchmark.
3. Not-yet-confirmed - anything about a specific customer's entitlements, integrations, security posture, retention/residency, legal basis, pricing, implementation timeline, or a quantified saving. Do not assert it. Say 'I want to get you the precise answer' and escalate.

The grounding is demo-derived, so most product-capability statements you can make live in tier 2, and most commercial and security specifics live in tier 3. When in doubt, drop a tier.

What always escalates

These topics are specialist-owned by default. Escalate rather than answer from memory:

• Security and data protection - retention, residency, encryption, access granularity, legal basis, certifications (F04).
• Commercial - pricing, packaging, which apps are entitled or integrated together, contract terms (F10).
• Integration - whether a specific system (telephony, case system, payer feed) connects, and the effort to do it.
• Quantified outcomes - any specific saving, ROI or benchmark for a customer (F03). A method and a hypothesis are yours; a committed number is not.
• Capability certainty - whether a feature seen in the demo is included, configured or available in production for that customer (F07, F08).
• Anything legally or ethically loaded - covert monitoring, using the tool to discipline unfairly.

Escalation is not weakness; it is the move that signals you are a safe vendor. 'That is important enough that I will bring in our specialist to confirm' builds more trust than a fluent guess.

What to say / do

Keep three phrases ready.

• To make a demo-tier claim safely: 'Here is how the product does this - and with your data it would reflect your own numbers, which we would baseline together.'
• To hold a line without killing momentum: 'The shape of the answer is X. The exact detail is something I will confirm with our specialist so you get it precisely, not approximately.'
• To refuse an over-claim a customer is pushing for: 'I could give you a number now, but it would not be one you could defend to your CFO. Let me get you one that will survive scrutiny.'

Sales: in S01 and S06, explicitly tag which of your claims require a specialist before you make them, and answer RFP items with approved facts or a named escalation owner - never with a hopeful guess.

CSM: when a metric dispute cannot be resolved with context (F06, C05), write an escalation packet - what you checked, what remains, who owns the next step - rather than offering a theory as fact.

Objections and honest limits

'Your competitor just answers these questions directly - why can't you?' - 'Because I would rather be right than fast. The answers I give you will hold up when your security and finance teams test them.' This reframes discipline as a feature.

'You keep saying you will confirm - do you actually know your own product?' - A fair challenge. You should be fluent in tiers 1 and 2 (the staircase, each app's value, the interpretation rules, the demo lab). Escalation is reserved for genuinely specialist or customer-specific facts, not a substitute for knowing the product. If you are escalating basics, close that knowledge gap.

Honest limit of this module: the tiers tell you how to classify a claim, not what the verified facts are. Build and keep an internal list of your current tier-1 facts and tier-3 escalation owners, and refresh it - a claim that was tier 3 last quarter may be approved tier-1 collateral now. When unsure which tier a statement is in, treat it as tier 3.