How do you build experience when AI handles all the experiences?
The promise is simple: let AI handle the easy work, and humans focus on the hard work, the challenging work, the fun work. But the
We speak with buyers and sellers every week, and one word keeps repeating.
Trust.
It keeps appearing in buyer conversations and seller conversations alike.
It’s more than a word though. It’s costing the telco industry millions.
When trust is missing, 18-24 month buying cycles become the default. This is the Buyer – Seller Chasm that we talk about a lot.
You’re probably already well aware of the pain-points around lengthy procurement events. But there’s something you might not have picked up on yet. Whether you realise it or not, almost all procurement approaches aren’t just a test of capability. They’re a test of trust.
Think about all the hoops we go through when assessing vendors. Functionality / capability might be the stated assessment criteria, but when you think about the approaches used, we’re actually assessing whether we can trust the vendor to deliver.
Procurement is the mechanism buyers use to reduce perceived delivery risk, commercial risk, and political risk. And when trust stays intangible, buying cycles drag on and on. Not because key decision-makers love meetings (well, some probably do). It’s mostly because they can’t get to a mental position where they feel the decision is safe yet.
This article discusses ways to get to trust a lot faster than the default, but we have to make it an intentional objective.
We’ll do that by including some of approaches we’ve learnt along the way that build trust faster.
.
We’ve sat through hundreds (or maybe even thousands) of vendor demos over the years. Two incredibly unexpected trust-enhancement patterns have shown up during those demos. They’re so unexpected that I’m not even sure if they were an intended sales technique (I think they were just inherent in those salespeople’s personalities).
The salespeople who openly describe their solution’s weaknesses or lack of fit often build trust faster than those who claim complete excellence.
When every answer from a vendor is “yes, we’re the market leaders at that”, Buyers don’t feel reassured. Instead, Buyers immediately feel like the Sellers are being dishonest.
That’s probably not the case most of the time though.
Each salesperson probably feels like they’re being truthful. It elicits thoughts of studies such as this, suggesting that up to 93% of drivers rate themselves as being more skillful than the average driver (the “better-than-average” effect where obviously only 50% can ever be better than average). I suspect almost every OSS vendor thinks they’re better than average.
So, as a Buyer, we need to help elicit honesty from Sellers.
How? We can ask questions that make it safer to be honest for example:
Then listen for specificity. Genuine, trustworthy answers usually include limitations, constraints, dependencies, failure modes and mitigations or workarounds. Low-trust answers tend to be vague, evasive, or framed as “we’ve never seen that before” or “we don’t have any faults” or “we try to help out our customers too much.”
This one move can change the tone of the procurement from only testing capability to also testing trust and partnership. Using this technique, you’re testing whether this vendor can tell the truth when they have something to lose.
.
If trust is a major element of the chasm (it is), the fastest bridge over it is a shared map of uncertainty and methodical risk reduction.
Whether they know it or not, each Buyer decision-maker is building a trust register. Some in their heads, others more systematically.
The mistake many Buyers make is keeping this list internal.
Instead, once you’re down to your selected shortlist, it makes sense to start sharing your specific reservations, concerns and risks with each vendor.
Be open about what / how you perceive risk with them. That might include:
This transparency doesn’t weaken your negotiating position. It strengthens your ability to get real evidence quickly and it reduces the risk of relationship breakdown later.
Our first book, “Mastering your OSS,” was written because there was always a disconnect between what the buyer thought they’d bought and what the seller thought they’d sold. Prime examples of disconnects were around data migration, change management, systems integrations, upskilling the team, pricing models and much more.
Removing the risks also helps with a silent killer in buying cycles. Hidden vetoes due to unstated risks.
There’s an old saying, “the confused (or fearful) mind says no.”
Stakeholders often don’t block a deal loudly or visibly. Instead, they delay it quietly or seek further rounds of information because they don’t trust what they’re seeing. A shared risk register makes it easier to surface and retire those veto points early. (note that some risks will be shared across all vendors, whilst others will be vendor-specific).
Buyers, I’d recommend for you to initiate this step.
.
Many procurement processes treat demos as not much more than ad-hoc theatre.
The fix is to define what evidence counts before the first demo – for internal and external stakeholders. To be totally clear, all demos must be in a language familiar to Sellers (since it’s their internal stakeholders deciding on whether the project proceeds).
Evidence usually needs to cover:
At PAOSS, we operationalise this using scenario packs. For each type of OSS functionality (eg Network Inventory), we have a baseline set of use-cases / scenarios that we then refine in collaboration with each customer.
These scenario pack templates combine:
Use scenario packs in two stages:
When you do this well, the demo stops being a performance and becomes an evidence-gathering exercise. And trust rises because you’re no longer relying on belief. You’re building proof and trust together. You’re also sharing operational knowledge with each other.
.
Trust is harder to establish when buyers can’t compare vendors easily or consistently. Seller solution collateral is generally designed to differentiate from their competitors. This is a case of intentionally avoiding apples-to-apples comparisons, but creates noise and complexity for evaluators. Noise creates delays. Delays create doubt. Doubts widen the chasm.
Combine two things:
A simple scorecard might include:
Vendor-agnostic guidance for Buyers helps by providing neutral structure such as:
We’re a strong believer in the importance of this lesson, but we’re also biased. This is one of PAOSS’ most important offers to assist OSS/BSS Buyers. We use our Blue Book OSS/BSS Vendor Directory to categorise over 750 listings.
We also use the Inverted Pyramid selection approach to eliminate what we refer to as the Three Forevers, of a typical RFP process. Together, the Vendor Directory and Inverted Pyramid approach aim to rapidly increase trust between buyers and best-fit sellers whilst helping to shrink the Buyer-Seller Chasm.
However, there’s no reason why you can’t establish your own scorecard and evaluation techniques similar to ours.
.
Everyone knows that pricing surprises are trust killers. Scope games are too.
But this still happens. Regularly!!
Typical Buyer approaches aim to push all cost and delivery risk onto Suppliers. Suppliers often accept this… until the contracts are signed…. and then find ways to push back such as using variations as a balancing tool.
This typical approach trashes trust and partnership from the outset, as described in this article.
Buyers often push for vendor transparency (“show me the numbers”), but without clarity around scope. Therefore, the deeper need is to establish clarity on:
.
Let me share a cautionary tale as an example.
A buyer (a T1 telco) started out with a long list of capabilities needed for their first major digital transformation in years. It was to be a pivotal investment in future operations.
Based on a back-of-paper-napkin calculation (it wasn’t a project I was directly involved with, but I had many involved connections), I estimated the contract value would be around $50m.
Over the next 2-3 years of ongoing POCs, the Buyer whittled down scope to fit within aggressive budget expectations. They eventually landed with Seller contracts that were less than $10m.
Unfortunately, the minimised scope left a significant gap from what the business actually needed. Buyer blamed Seller. Seller blamed Buyer. All were at loggerheads.
But the business needs gap still had to be resolved. The Buyer had to request additional scope projects. I’ve heard from insiders that there have since been around $200m in variations. That’s over 20x the original investment!!
That’s not just a commercial blowout. It’s a trust failure too. Most of it started by procurement trying to negotiate the lowest price.
Greater transparency is required. Buyers may choose to ask vendors to disclose:
Transparency isn’t only a seller / vendor responsibility. Buyers need to reciprocate transparency around:
There’s also a bigger structural issue here, as described in the link. Traditional procurement is often built around cost reduction and risk hand-off. Incentives for the procurement team involve pushing as much liability as possible onto vendors.
It can look like diligent “risk management” and cost reduction, but it often reduces trust and harms partnership from the outset. If the relationship begins as an adversarial contract exercise, it shouldn’t be surprising when trust gets buried and risk comes back later.
.
Testimonials and reference checks can be an important part of building trust in a Supplier’s ability to deliver. However, there can be a few provisos:
Run reference checks as an exercise of identifying the Seller’s ability to build strong partnerships as much as having the best solutions:
And be ruthless with one phrase: “out of the box”.
Too many RFPs are written against a wish-list of requirements that don’t really move the needle, but need customised development by Suppliers. Customisation means increased cost (up-front and TCO), harder future upgrades, non-standard support, more time, etc.
Request a written definition of what is:
.
Pre-sales purgatory happens when the POC / pilot isn’t designed to create a decision.
The cautionary tale described earlier is the perfect example here too.
There were endless rounds of POCs conducted over a period of years that were a huge cost to Buyer and Seller alike. The Buyer had seen certain functionality demonstrated and assumed it was in the contracted deliverables, but because the Seller had dropped modules to meet budgets, expected functionality had been excluded (and added back in by variation later).
A Proof of Concept (POC) is a demonstration of capability. A POC might be paid or unpaid (as mutually agreed by Buyer and Seller), but is not guaranteed to progress further than the POC. A subsequent decision is required on whether to proceed further.
A Proof of Value (POV) is similar to a POC, but is actually just a go / no-go decision gate in an approved contract. In other words, if the Buyer accepts that all essential criteria are met during the POV, then the long-term contract commences.
A POC/POV should be:
One goal is to “see it working” (and have a variety of end-users see it working, not just the delivery team). But more importantly, it’s to produce evidence that increases trust, reduces uncertainty, expedites stakeholder alignment and provides a stepping stone towards a future production build.
.
A surprising amount of trust is earned by delivery realism, not sales polish.
Buyers can ask for an implementation plan that includes:
When vendors can show project-level planning artefacts, it reveals whether they understand the size and scale of the programme and how complexity will be managed. It also gives your internal stakeholders something concrete to align resources around (see RACI / WBS view below), which reduces confusion and hidden vetoes.
Whilst every project is different, most task categories remain the same / similar from project to project.
The more reusable a Supplier’s delivery plan, the more reliably repeatable it should be.
At PAOSS, we use WBS (Work Breakdown Schedules) like the example shown in the diagram below. We have delivery planning templates for almost all of our main offers, including vendor selection projects. Each provides detailed examples of what “real” looks like, so buyers can separate refined, battle-hardened, credible plans from optimistic narratives. These templates need to be tweaked for each unique customer, but a majority of tasks will remain unchanged.
Notes:
You’re welcome to click on this link to freely navigate around the sample WBS above (you will be asked to create a free login on the DivvAI platform though).
.
One of the biggest hidden delays in procurement is the pause and reset that happens between POC/POV and implementation. Different teams, different artefacts, different understanding.
Trust and confidence leaks in the handover from Planning (Phase 1) to Implementation (Phase 2) in the diagram below.
The POC/POV/Pilot/Sandpit step is an important transition step.
Lab environments can close that gap by turning POC/POV into a runway for delivery.
If you keep a lab environment alive between evaluation (Phase 1) and production (Phase 2), you can use it for:
Working with real systems tends to be far more intuitive for new users than reading architecture documents or user manuals.
.
Most people will agree that trust is an important factor in getting a transformation project funded.
But most don’t realise just how important it is because it’s largely unsaid.
If you’re a Buyer and want to shrink an 18-24 month sales cycle, you’re probably not even thinking about trust explicitly. Most see it as an intangible that increases over time whilst getting familiar with the potential Sellers. Similarly, it’s easy for Buyers to push the onus onto Sellers to “just be more trustworthy.”
We need to be more scientific than that!
As you see from the lessons above, as Buyers, there are quite a few things we can do to actually fast-track trust. We have to start by treating trust as an objective, as an output by design, not a by-product.
If you’d like to discuss these and other techniques for getting across the buyer-seller chasm faster, please contact us.
The promise is simple: let AI handle the easy work, and humans focus on the hard work, the challenging work, the fun work. But the
I’d always assumed that more feedback loops meant better control, and faster / smarter / optimal operations. But what happens when each system has its
We’re already seeing it. AI is slowly infiltrating telecom, one little project at a time… monitoring, automating, optimising. In AI, we have one of the
We know telco customers want faster speeds.But is it possible that we’re focussed on the wrong type of speed?Here’s a hint: the real drag isn’t