Choose a customer experience software partner on evidence they have shipped the specific journey you need — onboarding, self-service, booking, support — rather than on general technology credentials. Ask how they research users, how they measure adoption after launch, and who owns the design decision when you and they disagree.
Customer experience work is judged after go-live, by whether people actually use what was built. That makes the selection criteria different from a straightforward software build, where a correct system delivered on time is a success.
Key takeaways
- Journey evidence beats platform evidence: Having built "a portal" is not the same as having built the flow your customers will use.
- Research capability is not optional: A partner who builds exactly what you specify will deliver your assumptions, including the wrong ones.
- Adoption is the deliverable: A system nobody uses is a failed project regardless of code quality.
- Set the baseline before build: Task completion, time to resolve, and contact volume for the target reason — measured now, not after.
Ask for the journey, not the technology
"We have built customer portals" tells you almost nothing. Ask instead for a journey close to yours: how a first-time customer got from arriving to completing the thing they came to do, what the drop-off was before and after, and what changed between the first release and the version that worked.
The detail in that answer is the signal. Partners who have genuinely shipped customer-facing work will talk about where people got stuck, what they had to remove, and which assumption turned out wrong. Partners who have mainly built internal systems will talk about architecture.
Assess four capabilities separately
Journey design is the ability to research real users, test a flow before building it, and reduce a wish list to the smallest thing that delivers value.
Integration is depth against your existing systems. Most customer experience failures are data failures: a portal showing status that is six hours stale, or an onboarding flow that cannot verify what the CRM already knows.
Operations is the staff side. Every customer-facing feature creates internal work, and a partner who has not asked who handles an exception has not finished designing the journey.
Measurement is instrumentation and the discipline to define success before build. Ask what they would measure and when they would expect it to move.
Insist on research, or supply it yourself
A partner who takes your specification and builds it precisely is not doing customer experience work. Someone has to test the assumptions with actual customers before the build, and if the partner does not do that, you need someone internally who will.
Ask concretely: how many customers would they speak to before scoping, what method would they use, and what would happen if the research contradicted your brief. The last question matters most. A partner with no answer will build what you asked for and let you discover the problem in production.
For what that means when the journey is a first customer interaction, see digital customer onboarding.
Agree how adoption will be driven
Customer-facing systems do not get adopted by existing. People arrive through the routes you build for them, and those routes are usually not part of a software scope.
Settle before signing: who updates the existing notifications, emails and letters to point at the new system; who trains the support team to answer with a link rather than a manual answer; and what happens to the old route, because if it stays available a meaningful share of customers will keep using it.
Ask whether the partner has done this work before, or expects you to. Either is workable. Discovering the gap after launch is not.
Define the measure before the build starts
Set the baseline while you still have the pre-launch situation to measure:
- Task completion rate for the journey in question
- Time from customer request to resolution
- Contact volume for the specific reason the project addresses
- Satisfaction on that journey specifically, not sitewide
Sitewide satisfaction moves too slowly and is influenced by too much else to attribute to one project. A journey-specific measure will move within a quarter if the project worked, which is what makes it useful as a decision tool rather than a report.
Settle design authority in advance
Disagreements about design are guaranteed. The question is who decides.
A partner with no authority will build whatever the loudest internal stakeholder wants, which produces a system designed by committee. A partner with total authority will occasionally be wrong about your business. The workable arrangement is that the partner owns the design of how the journey works, you own the business rules it must respect, and disagreements are settled by testing with customers rather than by seniority.
Write that down before the first design review. It is a five-minute conversation before a contract and a three-week argument afterwards.
Related guides
- Alongside How to Choose a Partner for Customer Experience Software, continue with Customer Portal Development: Workflows, Integrations, and Adoption.
- Alongside How to Choose a Partner for Customer Experience Software, continue with Digital Customer Onboarding: Steps, Metrics, and Examples.
If the work prompted by How to Choose a Partner for Customer Experience Software leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Customer Platform.
Ali Boran Gazel