# cx-pricing-objection-analysis > Use to analyse billing and pricing complaints, separating genuine pricing objections from billing defects and unclear communication. Trigger for "customers complaining about price", "billing complaint analysis", "why do customers dispute their invoice", "is our pricing a problem", unexpected-charge complaints, or a pricing decision that needs evidence from support. - Skill: `rulebase-co/cx-pricing-objection-analysis` (Agent Skill) - Install (CLI): `npx skillmds add rulebase-co/cx-pricing-objection-analysis` - Raw SKILL.md: https://api.skillmd.com/api/skills/rulebase-co/cx-pricing-objection-analysis/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Finance & Business - Author: rulebase-co (https://skillmd.com/u/rulebase-co) - Updated: 2026-08-19 - Page: https://skillmd.com/skills/rulebase-co/cx-pricing-objection-analysis --- # Pricing and billing complaints "Customers are complaining about price" is one of the least useful summaries in CX, because it collapses four different problems that arrive in the same words and have nothing else in common. ## Separate the four before counting anything - **Billing defect** — you charged the wrong amount. A bug, a proration error, a duplicate charge, a failed cancellation that kept billing. **Not a pricing objection.** Highest severity, fastest fix, and in regulated sectors often a reportable matter. - **Surprise** — the amount is correct and the customer did not expect it. Overage, a trial converting, an annual renewal, a price change that was announced somewhere they did not read. **A communication and product-design problem**, and usually the largest of the four. - **Value objection** — they understand the charge and think it is not worth it. The actual pricing signal. - **Affordability** — they understand it, accept it, and cannot pay. A completely different response, and in consumer or regulated contexts it may trigger duties around financial difficulty. **Never handle this as a pricing objection.** Getting the mix wrong sends the finding to the wrong place. A pricing review triggered by what is actually a proration bug wastes a quarter; a billing investigation triggered by a genuine value objection finds nothing and closes. Report the mix first, with the volume and revenue behind each. ## Billing defects need their own path Once separated, defects stop being an analysis and become an incident: - **Quantify the affected population**, not just the complainers. If proration broke for one plan change path, most affected customers have not noticed yet — and the ones who have are a sample, not the population. This is the single most important step, and it is the one most often skipped because the complaint volume looks small. - **Determine whether customers were over- or under-charged**, and for how long. - **Proactive remediation is usually the right answer**, and in many jurisdictions refunding only those who complained is not defensible. - **Escalate immediately** rather than filing it in a monthly report. Flag that whether this is a reportable matter is a decision for compliance and finance. ## Surprise is a design problem, and it is measurable For each surprise category, find the moment the customer *could* have known: - Was the charge communicated in advance, in a channel they use? - Was the trial end date visible in the product? - Did an overage warning fire before the threshold, or only the invoice after it? - Was a price change notified with the notice period the contract requires? Then check what proportion of the affected population complained. **A low complaint rate on a genuine surprise is not reassurance** — most people absorb it and quietly reduce trust, and some of them churn later without ever mentioning price. The fixes here are cheap relative to their effect: a threshold warning, a clearer renewal notice, an in-product indicator. Rank them by affected population rather than by complaint volume. ## Reading the value objection honestly This is the only one of the four that is actually about your pricing, and support is a biased place to measure it: - **You hear from customers who stayed to complain.** The ones who found it too expensive at evaluation never became customers, and the ones who left silently are absent. - **Objection volume tracks price changes, not price level.** A rise generates a spike that decays regardless of whether the new price is right. Measure the decayed steady state, not the spike, and never evaluate a price change in its first month. - **Segment it.** A value objection concentrated in one segment, plan or region is a packaging finding, not a pricing one — and packaging is usually cheaper to change. - **"Too expensive" often means "I can't tell what I'm paying for".** Where the objection comes with confusion about what the plan includes, it is a packaging and communication finding rather than a price-level one. Check before concluding the price is wrong. **What support data cannot tell you is what price you should charge.** It can tell you where the current price meets resistance, in which segments, and which of that resistance is really about clarity. Willingness-to-pay needs a different study; say so rather than letting a support analysis be read as a pricing recommendation. ## Affordability is a duty, not a discount decision Where a customer says they cannot afford it — as distinct from will not pay it: - **Route it to the process that handles financial difficulty**, if one exists. In regulated sectors this is likely a defined path with obligations attached. - **Do not treat it as a retention negotiation**, and do not let a discount decision substitute for whatever forbearance duty applies. - **Look for vulnerability signals** alongside it, and flag them. - **Count it separately in every report.** Folding affordability into "pricing objections" hides a conduct exposure inside a commercial metric. Whether a duty applies, and what it requires, is a question for compliance and legal. Flag it; do not answer it. ## Traps - **Cancellation reason codes are unreliable here.** "Too expensive" is the socially easy answer at cancellation and is over-selected. Where you have both the code and the conversation, report the disagreement rate. - **Currency and tax confusion** reads as a pricing complaint. Check whether the complaint is about the price or about VAT, FX, or a fee added at checkout. - **Payment failures are not pricing complaints.** A declined card generates billing-shaped contacts with a different cause entirely. - **Discount expiry** produces a spike that looks like a price objection and is really a surprise about a known end date. - **B2B: the complainer often is not the payer.** The person contacting support may not have seen the contract. ## Guardrails - **Never present the four categories as one number.** The whole value is in the split. - **Do not use the analysis to identify who will tolerate a price rise.** Differential pricing based on complaint behaviour, or on inferred vulnerability, is a conduct problem. - **Billing defect findings go to finance and compliance immediately**, not into the monthly pack. - **Cite ids and aggregates.** Billing conversations contain payment details, partial card numbers and financial circumstances. Do not paste them. ## Present results to the user 1. **The four-way split**, with volume and revenue behind each. Before any conclusion. 2. **Billing defects, escalated separately**, with the estimated affected population — not just the complainers — and the over/under-charge direction. 3. **Surprise categories**, each with the moment the customer could have known and the affected population, ranked by population rather than complaints. 4. **Value objections by segment and plan**, on decayed steady state rather than a post-change spike, with the clarity-versus-level distinction made. 5. **Affordability cases counted separately**, routed to the financial-difficulty process, with vulnerability signals flagged. 6. **What this cannot answer** — willingness to pay, lost prospects, and the right price.