The demo was sharp. The proposal looked thorough. The first internal meeting happened — and that's when someone asked "so, walk us through how this is going to work for our specific process." And the answer was some version of: "great question, let's explore that together."
Together. After you signed. After the kickoff. After your team cleared their calendars to support an implementation that was supposed to already have a plan.
If you've been through a CRM or ops implementation that started with clarity and ended in ambiguity, you already know the pattern. The question isn't whether bad implementations exist — it's how to spot the difference before it costs you three months and a demoralized team.
Most evaluations focus on the wrong things: certifications, years in business, the logos on the website. Those signals tell you a partner exists. They don't tell you whether they know how your business works before they touch your systems.
What you're really trying to find out is whether this person has already thought through your implementation — or whether they're going to think through it with your time and your money.
There's a version of every implementation where the partner arrives with a blueprint. They've mapped the objects, defined the pipelines, identified where your existing stack connects, and can show you — before you commit — what the result looks like. That version of the engagement is fast, predictable, and low-friction for your team.
There's another version where the partner arrives with a methodology and good intentions, and the actual design happens in workshops. Those workshops run long. Your team spends hours in discovery calls that feel like the partner is learning the basics of your business. The timeline slips. Scope expands. And at the end, you have something that works — eventually — but the cost was three times what you expected in effort, not just money.
The questions below are designed to tell you which version you're walking into.
This is the first filter. A partner who has built the same model before — for a business like yours — should be able to show you a working version of it. Not a wireframe. Not a slide deck with screenshots. An actual configured environment you can click through.
If the answer is "we'll define that during discovery," that's not a methodology — that's a postponement. You're being asked to fund the design work under the label of implementation. Those are two different things, and they shouldn't cost the same.
A partner who can show you the model before you commit is a partner who already knows what they're building. That's the only kind worth hiring.
This question surfaces whether the partner understands how your business actually runs. In companies that sell projects, the moment a deal closes isn't the end of the sales process — it's the beginning of the delivery process. How that transition happens determines whether your operations team gets complete information or has to chase it down.
A partner who has solved this knows the answer immediately: here's what triggers the handoff, here's what the ops team receives, here's how the project record connects to the deal record so the salesperson doesn't have to ask a single question to know what's happening on delivery.
A partner who hasn't solved it will give you a conceptual answer. "We'll design a process for that." That's a signal to keep asking.
Your stack isn't a blank slate. You have a CRM, probably a project manager, maybe an ERP. The data in those systems represents years of operational history — client relationships, project patterns, financial records. A good implementation doesn't ignore that. It designs around it.
Ask the partner to walk you through the integration model. How does your ERP talk to the new system? By ID? By file sync? In real time or in batches? What happens when there's a conflict between systems — which one is the source of truth for which data?
If the partner can answer those questions specifically, they've built integrations before. If they say "we'll assess that during onboarding," the integration work is going to be improvised — and improvised integrations are where implementations fall apart six months after launch.
This question cuts through every timeline estimate and straight to the real cost of the engagement: your team's time. Implementations fail not because the software is wrong, but because the business ran out of capacity to support the process while also running the business.
A partner who respects this has already designed the engagement to minimize what they need from you. They come with questions, not workshops. They come with a draft, not a blank document. They show you something and ask you to react — they don't ask you to build from scratch in a shared screen.
The answer you want sounds like: "We've already built the base structure. We need approximately X hours from your team over Y weeks to validate, adjust, and train. Here's what that looks like by week." The answer you don't want is any version of "it depends on how complex your process turns out to be."
Every proposal has a scope. The question is whether the scope is honest or optimistic. Ask the partner to walk you through what happens when you need something that isn't in the original agreement. Is there a change order process? What does it cost? Who decides whether something is in scope?
Partners who have mature processes answer this without hesitation. Partners who are still figuring it out get vague. The vagueness costs you later.
Here's the pattern that distinguishes a partner who knows what they're doing: they have already built a version of your implementation, and they can show it to you. The conversation isn't about what's possible — it's about whether what they've already built fits what you need, and what adjustments are required.
That changes the entire dynamic of the evaluation. You're not assessing a pitch — you're reviewing a draft. You can react to something concrete instead of trying to evaluate a promise.
It also changes the implementation itself. When the partner already has the blueprint, the first weeks of the engagement aren't about discovery — they're about validation and configuration. The timeline compresses. Your team's involvement is focused and bounded. You know what you're getting before you commit to getting it.
How a partner behaves during the sales process tells you exactly how they'll behave during implementation. A partner who comes to the first conversation with a prepared demo of your specific use case, who can answer operational questions without deflecting to discovery, who tells you clearly what's in scope and what isn't — that partner has done this before and is operating from a real methodology.
A partner who says "let's start with a discovery call to understand your goals" after you've already explained your goals in writing is telling you something important: their process starts from zero every time. That's not bad for them. It's expensive for you.
The questions above aren't just due diligence — they're the fastest way to find out which kind of partner you're talking to. The right one will welcome them. The wrong one will deflect them.
If you want to see whether SAP ASAP answers these questions — the objects, the pipelines, the handoff logic, the financial visibility layer, all of it mapped before you commit — it's at sap-asap.mx/forcompaniesthatsellprojects. The model is live. Judge for yourself.