You've taken three discovery calls this month. All three partners said the same things. They've worked with companies like yours. They understand professional services. They have a proven methodology. They'll send a proposal next week.
You hang up and you don't know more than you did before the call. You can't tell which one is going to deliver and which one is going to spend the first six weeks after signing figuring out what they sold you. The proposals will arrive, they'll all be in the same range, and you'll end up choosing based on something soft — who seemed more confident, who had the better-looking deck, who got back to you faster.
That's not a selection process. That's a coin flip with extra steps.
The questions most buyers ask during evaluation — "how many years of experience do you have," "what's your methodology," "can you share case studies" — sound rigorous but filter nothing. Every partner has rehearsed answers. Every partner has logos on a slide. Every partner has a methodology with a name and a diagram.
The problem isn't that these questions are wrong. The problem is they ask about the past. They tell you what the partner has done, not what they're going to do for you specifically. And what they've done for someone else is only loosely correlated with whether they can architect your operation.
The partners who underperform aren't bad at sales — they're often great at sales. They're bad at the work that happens after the sale. By the time you find that out, you've already paid the deposit.
The single most useful question in a partner evaluation is some version of "based on what you know about my business so far, how would you structure this?" Ask it in the first or second conversation, before they've done any paid discovery.
Watch what happens. A partner with real experience in your model will start drawing — literally or verbally. They'll talk about your sales pipeline and how it should connect to delivery. They'll mention specific objects, specific stages, specific handoffs. They'll have opinions about what you probably do wrong because they've seen it ten times before.
A partner without that experience will redirect. They'll say "that's a great question and exactly what we'll cover in the discovery phase." That answer is the tell. It means the architecture doesn't exist yet — they're going to figure it out using your money and your time after you sign.
These aren't trick questions. They're questions designed to surface whether the partner has a real model of your business or is going to build one on your dime.
If they can show you actual structure — objects, pipelines, relationships — for a business that resembles yours, they have a model. If they show you a generic sales pipeline demo, they don't. The difference between "here's the standard deal pipeline" and "here's how a deal connects to a project, which connects to tickets per delivery team, which roll up costs into a margin field on the deal" is the difference between someone who's done this and someone who hasn't.
This is the question that exposes whether they understand your business model at all. Companies that sell projects live or die on that handoff. A partner who doesn't have a clear answer — what triggers it, what information transfers, who owns what after — is going to leave that exact gap open in your implementation. You'll discover it three months in, when your delivery team starts complaining that they don't know what was sold.
A partner who knows what they're doing can tell you specifically: how many hours per week from which roles, what decisions you'll need to make and when, what they need from you in week one versus week six. A partner who's going to improvise gives you vague answers about "close collaboration" and "workshops." The vagueness isn't humility — it's that they don't know yet, because they haven't planned it.
The right answer is some version of: a blueprint document that shows exactly how your operation will work in the system, that you review and approve before a single thing is built. If the answer is "we start configuring after the kickoff," you're about to pay them to discover your business while building it. That's a long, expensive process with predictable rework.
This is the most underrated question. A partner with real conviction will have opinions about things you shouldn't try — features you're asking about that don't make sense, integrations that aren't worth the complexity, scope you want to add that will hurt the project. A partner who says yes to everything is telling you they don't have a point of view. They'll build whatever you ask, including the wrong things, and the result will reflect that.
Trust in an implementation partner isn't about likability or chemistry. It's about whether they can show you, before you sign, what you're going to receive. Everything else is decoration.
The partners worth working with operate on a simple principle: when you approve the proposal, you already know exactly what's going to be built. There are no surprises during implementation because the surprises happened during the design phase — which you reviewed and approved. Implementation becomes execution of a plan you've seen, not discovery you're paying for.
That's the standard. If a partner can't get you to that level of clarity before you sign, the trust problem is structural — it's not going to improve after the contract is signed. It usually gets worse.
Here's how to run this in practice without turning your evaluation into a six-month process.
First call: tell them about your business. See how much they extract in 45 minutes and what hypotheses they form. If they leave the call without any real point of view about your model, that's information.
Second call: ask them to come back with a sketch — even a rough one — of how they'd structure your operation in the system. Not a proposal, not pricing. Just the architectural thinking. The partners who can do this in a week are showing you they have a library of mental models to draw from. The partners who say "we'll need a paid discovery phase before we can show you anything" are showing you they don't.
Third interaction: ask the five questions above directly. Compare answers across partners. The differences will be obvious. You're not looking for the most polished answers — you're looking for the most specific ones.
By the end of that sequence, you'll know which partner has a real model and which ones are going to learn on your time. The selection will make itself.
SAP ASAP is built around exactly this principle: you should be able to see how your operation will work in the system before you sign anything. The product page for companies that sell projects shows the full object model, the pipeline structure, how preventa connects to project execution, how financial data rolls up — not as a teaser, but as the actual architecture you'd receive. The intent is for you to arrive at a sales conversation already knowing what you're buying. If the model makes sense to you, the rest of the process is just execution. If it doesn't, you've saved yourself a discovery call.
Take a look at the model and run it through the questions above. If the answers are already on the page, that tells you something about how the engagement will run.