If Your Payments Product Needs a Demo, Your UX Has Failed
FX and Float: Operator Note
If a customer using your product cannot figure out how to send money, check a rate, or complete onboarding without a 30-minute screen share with your sales team, you have a problem. It’s not just your UX but a broader product problem. The sales team giving a demo is not the solution; it is a symptom of this problem.
The Consumer Payments world figured this out a decade ago. Wise does not demo how to make a transfer. Revolut does not walk you through a screen share to open an account. Pix does not require a sales call. You open the app, you do your thing, and you are done. The standard for consumer cross-border payments is zero-touch onboarding and self-serve everything.
It seems that the B2B payment players have missed this trick. They have normalised a workflow in which a business customer fills out a form, waits for a call, sits through a product walkthrough, asks obvious questions that the interface itself should have answered, and then, maybe, starts using the product. Entire sales organisations have been built to compensate for products that cannot explain themselves.
We have convinced ourselves that this is the way to do things. Why? Because “B2B is complex,” and “our customers need hand-holding,” and “the compliance requirements make self-serve impossible.” These are less explanations and more excuses dressed up as industry wisdom.
I do appreciate that B2B payments involve more complexity than consumer payments. Multi-currency accounts, batch payments, approval workflows, and compliance documentation – all are complex. But complexity should not be a justification for bad design. It should be the reason to invest more in good design. The harder the underlying process, the more the interface needs to absorb that complexity. That is what product design is for.
When a payments company requires a demo, what they are really saying is that they have built based on what they understand, and not based on what the customer needs. They have designed their flows based on their internal architecture rather than the user’s behaviour. And now they have hired people to translate it for customers. The demo is this translation.
The cost of this is much more than bad UX. Every demo delays the sales cycle from minutes to days. Every sales call adds to the CAC. Down the line, these customers also need more support tickets, account management, and handholding throughout their lifetime, because the product never taught them to be independent. The dependency, which starts with the demo, stays long enough to impact the LTV.
The companies that will win in B2B payments are the ones building products with zero-touch; that a finance executive can sign up for, configure, and send a first payment through - without needing to speak to a human.
Needing human support to complete a basic workflow means the product has failed at its primary job. The need for demos is not a ‘feature’ or ‘USP,’ but rather an outstanding product and design debt.