At some point, every pricing person gets this request:
“We should sell this based on complexity like low, moderate, and high.”
It sounds reasonable. Even intuitive.
Until you try to actually price it.
Because “complexity” is one of those words everyone nods at… and no one defines the same way. If you don’t force clarity upfront, you’ll end up with:
- Sales making it up on the fly
- Customers questioning every quote
- Margin getting quietly destroyed
I’ve seen this play out dozens of times. It never ends well unless you slow it down and structure it properly.
So here’s how to handle it practically.
The Core Problem with “Complexity” as a Pricing Dimension
“Complexity” isn’t a metric.
It’s a placeholder for:
- Effort
- Risk
- Unknowns
- Customer-specific variability
And the moment you price something that isn’t clearly defined, three things happen:
- Sales fills in the gaps (inconsistently)
- Customers push back (“why am I medium vs small?”)
- Finance loses predictability
If it can’t be measured, or at least consistently classified, it shouldn’t be a pricing input yet.
Step 1: Force the Team to Define What “Complexity” Actually Means
Don’t accept “we’ll know it when we see it.”
Push back with specific questions.
Questions You Should Ask Immediately
1. What specifically makes something “complex”?
- Number of integrations?
- Custom configurations?
- Data volume?
- Implementation time?
If the answer is “a mix of things,” you’re not done yet.
2. Can two different people classify the same deal the same way?
- If not → it’s subjective
- Subjective → not scalable
This needs to be an objective and repeatable process.
3. Does complexity drive cost, value, or both?
- Cost → affects margin
- Value → affects willingness to pay
This determines how you price it.
4. When does complexity show up?
- Before the sale (clear requirements)
- During implementation (unknowns)
If it shows up later, pricing it upfront gets risky.
5. What’s the worst-case scenario if we misclassify?
- Underpricing → margin loss
- Overpricing → lost deal
Which one hurts more? That matters.
Step 2: Break “Complexity” Into Actual Drivers
This is where you turn something vague into something usable.
Instead of:
“Complexity = Low / Moderate / high”
Translate it into components like:
- Number of integrations
- Number of workflows or configurations
- Data volume or scale
- Implementation hours required
- Level of customization
- Support intensity
You don’t need 10 variables.
You need 3–5 that explain 80% of the variation.
Step 3: Choose How to Price It (You Have 3 Real Options)
Once you’ve clarified complexity, you have to decide how it shows up in pricing.
Option 1: Build It Into Tiers (Simple, But Risky)
Example:
- Low = $10K
- Moderate = $20K
- High = $40K
Pros:
- Easy for sales
- Clean pricing page
Cons:
- Hard to define boundaries
- Risk of misclassification
- Customers argue placement
When to use:
- Complexity is predictable
- Differences are large and obvious
Option 2: Use Add-Ons (Most Flexible)
Example:
- Base product: $15K
-
- Integrations: $5K each
-
- Custom workflows: $3K each
Pros:
- More precise
- Scales with actual need
- Easier to justify
Cons:
- More moving parts
- Slightly harder to sell
When to use:
- Complexity varies a lot
- You can isolate components clearly
Option 3: Hybrid Model (Usually Best)
Example:
- Base tiers (small/medium/large customer)
- Add-ons for complexity drivers
This keeps:
- Top-level pricing simple
- Complexity priced accurately underneath
Step 4: Make It Objective (This Is Non-Negotiable)
If you go forward with “complexity,” you need rules.
Not guidelines. Rules.
Example of a Bad Definition
“High complexity = lots of integrations and customization”
That’s useless.
Example of a Good Definition
- Small Complexity
- 0–2 integrations
- <20 implementation hours
- Medium Complexity
- 3–5 integrations
- 20–60 hours
- High Complexity
- 6+ integrations
- 60+ hours
Now:
- Sales can classify it
- Customers can understand it
- Finance can forecast it
Step 5: Decide When Complexity Is Priced
This part gets overlooked and causes the most issues.
Option A: Price It Upfront
You define complexity before the deal is signed.
Risk: You guess wrong
Benefit: Predictable pricing
Option B: Price It After Discovery
You say:
“Final pricing depends on complexity after assessment”
Risk: Slows sales cycle
Benefit: More accurate pricing
Option C: Price a Baseline + Adjust Later
Example:
- Base includes “small complexity”
- Medium/high priced after scoping
This is often the most practical.
Real-World Example (Where This Goes Wrong)
A SaaS company introduced:
- Small: $25K
- Medium: $50K
- High: $100K
No clear definitions.
What happened?
- Sales labeled almost everything “small” to close deals
- Implementation teams got overwhelmed
- Margins collapsed on “small” customers
They fixed it by:
- Breaking complexity into integrations + workflows
- Charging per component
Revenue went up. Chaos went down.
Common Mistakes to Avoid
- Treating “complexity” as a single variable
- Letting sales decide complexity without rules
- Pricing before understanding drivers
- Overcomplicating the model with too many inputs
- Hiding complexity instead of structuring it
Key Takeaways
- “Complexity” is not a pricing input until it’s clearly defined
- Break it into 3–5 measurable drivers
- Choose the right structure: tier, add-on, or hybrid
- Make classification objective and repeatable
- Decide when complexity is priced (before or after sale)
- If it’s vague, it will be misused—guaranteed
FAQ: Pricing Complexity Tiers
What does “complexity” mean in pricing?
It typically refers to differences in implementation effort, customization, integrations, or support requirements but must be clearly defined to be usable.
Should I use small, medium, high tiers?
Only if you can define them objectively. Otherwise, use add-ons or a hybrid model.
How do I make complexity pricing fair?
Tie it to measurable factors like integrations, hours, or configurations not subjective judgment.
What if complexity isn’t known before the sale?
Use a baseline price and adjust after discovery, or include ranges in your proposal.
Can complexity be bundled into base pricing?
Yes, but only if variability is low. Otherwise, you risk underpricing high-complexity customers.
What’s the biggest risk of vague pricing tiers?
Inconsistent application by sales teams, leading to margin loss and customer confusion.
If you handle this right, “complexity” stops being a vague idea and becomes a controlled pricing lever.
If you don’t?
It becomes a loophole everyone drives through.
