Fallout is absorbed by a team, not reduced
Exceptions are worked by people rather than traced to causes. The queue is stable because it is staffed, which makes it invisible in every report except the headcount one.
Salesforce · Communications Cloud
Live is not the same as working. We find out which one you have.
Communications Cloud optimization is a bounded project for a platform that is already in production and underperforming — too much order fallout, a catalog nobody can change quickly, carts that time out, adoption that never arrived, or a change cost that keeps rising. Twopir Consulting measures it against a baseline, traces the symptoms to causes, and delivers a remediation plan ranked by return. Measurement first. Opinions after.
12+
500+
40+
250+
Trusted by 500+ organizations — including connectivity and communications providers whose live Salesforce platforms Twopir Consulting has assessed and remediated.
What We Assess
- Salesforce Partner
- Order Flow-Through
- Catalog Health
- Cart & CPQ Performance
- Integration Reliability
- Technical Debt
- Adoption & Usability
- Change Cost
Six complaints that share about three causes
Operators describe these as separate problems. In assessment they usually collapse into a small number of decisions taken early in the original build.
The catalog has become unmanageable
Thousands of products, overlapping offers, and rules nobody wants to touch. Launching anything new means finding something similar and copying it, which makes the problem worse each time.
The cart is slow enough to lose orders
Configuration and pricing take long enough that agents work around the system and customers abandon. Usually a modelling problem — too many options evaluated per interaction — rather than a capacity one.
Adoption never really happened
Agents keep spreadsheets, sales keeps quoting outside the system, and the data that should be a single source of truth has quiet competitors. Adoption failures are almost always design failures wearing a training label.
Change costs more every quarter
A growing custom surface means every change needs more regression, more investigation and more caution. The trend is the diagnosis: rising change cost has a cause, and it is usually structural.
Nobody can prove any of this
The platform is managed by anecdote because flow-through, fallout rate and cycle time are not measured. Without a baseline there is no way to tell whether last quarter's work helped.
How Optimization Works
Measure first, because most diagnoses are wrong
Communications Cloud optimization is a bounded assessment-and-remediation project on a live platform. It starts with measurement against a baseline: order flow-through rate and where orders actually fail, catalog size against what is actually sold, cart and pricing response times under real conditions, integration error and retry rates, the size and shape of the custom surface, and the lead time from an approved offer to a sellable one. Only then does anything get diagnosed.
That order matters because the reported symptom is usually not the cause. Slow carts are more often a catalog modelling problem than an infrastructure one. High fallout is more often a serviceability-sequencing problem — selling what cannot be delivered at that address — than an integration reliability problem. Poor adoption is more often a journey-design problem than a training problem. Remediating the symptom in each of those cases spends real money and moves nothing, which is why we will not quote remediation before measuring.
The output is a remediation plan ranked by return with effort attached, so you can choose where to stop. Twopir Consulting will deliver the remediation, but the assessment stands on its own — it is deliberately useful to a client who takes the plan and executes it internally, or gives it to somebody else. An assessment that only makes sense if you also buy the remediation is a sales document rather than an assessment.
Which engagement do you need? If the platform is not built, that is implementation. If it works and needs steady ownership, that is support and managed services. If you need new capability built, that is customization. Optimization is for a platform that is live, underperforming, and not yet understood.
Six measures, and what each one tends to reveal
Each is captured against your own current state, so improvement is measured against where you actually started rather than against an industry figure that describes somebody else.
Order flow-through and fallout
What share of orders complete without human intervention, and precisely where the rest stop. Broken down by product, channel and failure type — because an aggregate fallout rate hides the fact that most fallout usually comes from a small number of causes. Commonly reveals that qualification is happening after the order rather than in the cart.
Catalog size against catalog use
How many products exist, how many were sold in the last twelve months, and how much of the model is duplication. Also how long it takes to launch a new offer end to end. Commonly reveals a portfolio several times larger than the business needs, and offer lead times dominated by finding something to copy.
Cart and pricing performance
Configuration and pricing response times under realistic conditions, not on an empty org. Commonly reveals a modelling problem — too many options, rules or price list entries evaluated per interaction — rather than a platform capacity problem, which means the fix is in the model rather than in more infrastructure.
Integration reliability
Error rates, retry volumes, timeout frequency and how many exceptions are recovered manually. Commonly reveals interfaces without idempotency producing duplicate work under load, and exception volumes that nobody has ever reported on because they are absorbed by a team.
Custom surface and technical debt
How much custom code and extension exists, what surface it uses, how much of it duplicates product capability, and what it costs at each platform release. Commonly reveals extensions built before the product could do something it now does natively, carried forward because nobody documented why they existed.
Adoption and workarounds
Where the real work happens — which is often not in the platform. We look for spreadsheets, side systems and manual steps that indicate the designed journey did not fit the job. Commonly reveals a journey-design problem that has been treated as a training problem for two years.
What the complaint usually turns out to be
Not a promise about your platform — a statement of where we look first, based on what these symptoms usually mean.
Reported symptom, usual cause, and the remediation that follows
| Reported symptom | Where the cause usually is | What remediation looks like |
|---|---|---|
| High order fallout | Serviceability checked after the order, not in the cart | Move qualification into the cart; model the exception properly |
| Slow cart and pricing | Catalog modelling — too much evaluated per interaction | Restructure the product model; reduce rule and price-list breadth |
| Offers take months to launch | Logic in code rather than in the catalog model | Move rules back to configuration; enable the product team |
| Duplicate charges or activations | Interfaces without idempotency, exposed under load | Idempotency keys and retry semantics per interface |
| Change costs keep rising | A custom surface that grew without a boundary | Inventory, retire what the product now does, isolate the rest |
| Poor adoption | Journey design that does not match the actual job | Redesign the journey with the people doing the work |
| Platform releases hurt | Extensions built against internals, no regression suite | Move to supported extension points; build the suite |
The middle column is where we look first, not a prediction. The assessment exists precisely because these are tendencies rather than certainties — and because remediating the wrong cause is expensive, slow, and does not show up as a failure until the symptom returns.
An assessment that stands on its own
Typically four to six weeks to the plan, depending on platform size and how much instrumentation already exists.
Instrument & Baseline
Establish what is actually measurable and fill the gaps. Many platforms cannot report fallout by cause or offer lead time at all, so the first task is often making the platform observable enough to assess.
Measure Against Real Use
Flow-through, catalog use, cart performance, integration reliability, custom surface and adoption — captured under genuine conditions and volumes rather than in a clean sandbox.
Trace to Causes
Symptoms grouped and traced back to the decisions that produced them. This is where six complaints usually collapse into three causes, and where the plan starts to become affordable.
Rank by Return
Every remediation item carries an estimated effort and an expected effect on a measured number. You choose where to stop, and the reasoning is visible rather than asserted.
Remediate & Re-measure
We deliver the plan, or your team does, or somebody else does. Either way the same measurements are repeated afterwards — because remediation that is not re-measured is a belief, not a result.
What the assessment puts in your hands
Deliberately useful whether or not we do the remediation.
Numbers where you had anecdotes
Flow-through, fallout by cause, catalog use, cart performance and change cost — measured on your platform, so every later claim of improvement has something to be measured against.
Causes, not a list of symptoms
Complaints traced back to the decisions that produced them, which is usually a much shorter list than the one you started with and a far cheaper one to act on.
Remediation ranked by return
Each item with estimated effort and expected effect on a measured number, so you can stop wherever the return stops justifying the spend.
A defensible rationalisation case
What is actually sold against what exists, with a retirement plan — the analysis that makes the argument for reducing a portfolio winnable internally.
The real cost of the custom surface
What exists, which extension surface it uses, what duplicates product capability, and what each item costs at every platform release.
A document you can act on without us
The assessment is written to be executed by whoever you choose. An assessment that only works if you also buy the remediation is a sales document.
Related Twopir work
Related: order management & automation where fallout is the dominant finding, customization where technical debt is, and support & managed services to hold the gains afterwards.
We will not quote remediation before we have measured
A fixed-price fix for an undiagnosed problem is a guess with an invoice attached. The assessment is deliberately sold and priced on its own so that the diagnosis is not shaped by what we would like to build next.
We measure before we diagnose
Most reported symptoms have a cause somewhere other than where they appear. Slow carts are usually a modelling problem; high fallout is usually a sequencing problem. Measurement is what stops expensive work on the wrong thing.
We make the platform observable first
Many platforms cannot report fallout by cause or offer lead time at all. Instrumenting is often the first deliverable, and it keeps paying long after the assessment finishes.
We rank by return, with effort attached
Every item carries an estimated cost and an expected effect on a measured number, so you can stop where the return stops. Plans without that column are wish lists.
We write it to be executed by anyone
The plan is useful if your team delivers it, or another partner does. Tying an assessment to our own remediation would compromise the one thing that makes it worth having.
We re-measure afterwards
The same measurements are repeated once remediation lands. Improvement that has not been re-measured is a belief, and beliefs are how platforms drift for years.
Answers before the first call
With measurement, not with a rebuild. We instrument the platform so that order flow-through, fallout by cause, catalog use against catalog size, cart and pricing performance, integration reliability and the size of the custom surface can actually be reported — many live platforms cannot report several of those. Then we measure under real conditions and trace the symptoms to causes. Six complaints commonly collapse into about three decisions taken early in the original build, which makes the remediation plan far shorter and cheaper than the complaint list suggests.
Usually not. Slow configuration and pricing in a catalog-driven system is more often a modelling problem than a capacity one: too many products, options, rules or price list entries being evaluated for each interaction, because the product model was built by extension rather than designed. Adding infrastructure to a modelling problem produces a marginal improvement at a permanent cost. We measure response times under realistic volumes and conditions rather than on a clean sandbox, and in most cases the remediation is restructuring the product model and reducing rule and price-list breadth.
Start by measuring where it actually comes from, broken down by product, channel and failure type, because an aggregate fallout rate almost always hides the fact that a small number of causes produce most of the volume. The most common single cause is upstream rather than technical: selling something that cannot be delivered at that address, because serviceability and qualification are checked after the order is placed rather than in the cart. Moving qualification into the cart typically removes more fallout than any downstream reliability work. After that it is idempotency on interfaces, and modelling exceptions so they are visible, routed and countable — fallout you cannot count is fallout you cannot reduce.
Typically four to six weeks, depending on platform size and how much instrumentation already exists. It produces a measured baseline of your platform, a root-cause analysis that groups symptoms back to the decisions that caused them, and a remediation plan where every item carries an estimated effort and an expected effect on a measured number. It also produces a catalog rationalisation case — what is actually sold against what exists — which is usually the analysis clients find most immediately useful internally.
Yes, and it is written for that. The plan is intended to be executable by your own team or by another partner, and it is priced and sold separately from any remediation work. An assessment that only makes sense if you also buy the delivery is a sales document, and it compromises the diagnosis — the temptation to find problems that match what you would like to build next is exactly what independence is supposed to remove.
It overlaps but it is narrower and deeper. A general Salesforce health check looks at org hygiene, security, storage, automation sprawl and best-practice adherence across the platform. Communications Cloud optimization focuses on the things that determine whether a telecom commercial platform performs: order flow-through and fallout causes, catalog health and offer lead time, cart and pricing behaviour under load, integration reliability, and the custom surface's release cost. Both are worth doing; they answer different questions, and a generic health check will not tell you why your orders are falling out.
Then we say so, with the evidence and the comparison — what remediation would cost and achieve against what a rebuild would cost and achieve. It is an uncommon conclusion because most underperforming platforms have a small number of fixable structural causes rather than a fundamentally wrong foundation. But it does happen, usually where the original build lifted and shifted a legacy catalog wholesale, and telling you late would be considerably more expensive than telling you in week five.
Next Step
Tell us what is not working. We will measure it before we agree.
An assessment starts with instrumentation and a baseline, not a proposal. You get measured numbers, root causes, and a remediation plan ranked by return — written so you can act on it with or without us.
Speak with a team that measures before it recommends
