Index

Overview

Pleo is one of Europe's leading business expense management solutions: reimbursements, invoices, and smart virtual and physical company cards for hundreds of thousands of companies across the continent.

My time at Pleo came in two chapters.

In the first, I led design for Pleo's wallet, funding infrastructure and credit products.

Working at the intersection of product strategy, financial infrastructure and design, I helped shape how money moves through Pleo, from instant top-ups and automated funding to credit-backed spending.

For long stretches without a PM or design manager, I partnered directly with engineering leadership on the roadmap, aligned commercial and risk stakeholders, and turned a critical revenue problem into a series of products that improved customer outcomes and company performance.

In the second, I led design for Pleo's product-led onboarding.

As the company scaled across Europe, I led the shift from sales-led to product-led growth, turning a complex, human-assisted signup into a self-serve experience across 16 markets.

2021 – 2024

Chapter 1

Designing a wallet that never runs dry

The Pleo wallet is the financial control center for all companies using Pleo to manage spending and expenses. It's typically managed by admins, who are required to add money to it in order to enable spending for invoices, card payments, and subscriptions.

However, keeping that wallet funded at the right level is harder than it sounds, and when it runs dry, spending stops.

More than 50% of all Pleo customers between 2021 and 2022 experienced a transaction decline due to insufficient funds in their Pleo wallet.

Why it's a problem

Pleo makes money when there's a spend from the wallet. If there's a declined spend, there's no revenue, and no profit. A decline is also a moment of friction and embarrassment for the employee standing at the checkout.

How do we solve this?

Three bets, each attacking the problem from a different angle:

  • Optimise for speed: make it faster to add money to the wallet, so funding is never the thing that holds spending up.
  • Automate the wallet: take topping up off the admin's plate entirely, so no one has to think about keeping it funded.
  • Introduce credit: flip the model: what if the wallet were credit-first, so spending isn't gated on a balance at all?
The Pleo wallet
The Pleo wallet

The team

1 designer (me), 1 engineering manager, 1 product manager, 1 frontend engineer and 4 backend engineers.

For over 8 months the team didn't have a product manager, so I led that function in collaboration with the engineering manager.

Bet 1 — Optimising for speed

Open Banking in the UK

The idea was simple: the faster an admin can move money into the wallet, the less often it runs dry. The biggest lever was the top-up itself.

Top-ups had always been manual bank transfers: slow, hard to trace, and clumsy to do, which made a customer's first top-up a poor first impression. So we partnered with Yapily, Europe's largest provider, to build a faster, personalised top-up experience for Pleo's customers across the UK and Europe with Open Banking.

The design process

The work ran as a loop, not a line. It moved from user research through design, testing and build, into a beta rollout and the feedback that fed the next round.

We collaborated closely with Yapily, NatWest and JP Morgan the whole way, validating each flow with real customers before shipping to the first 15% of UK businesses.

Discovery

We started by sitting with admins — the people who actually keep wallets funded — to understand how money moved through their companies and where it got stuck.

The kick-off mapped the funding journey end to end, surfacing the moments where a wallet quietly ran dry without anyone noticing until a card was declined.

For GDPR reasons, I'm not able to show screenshots of UXR transcripts and usability tests.

Design explorations

The first question we asked ourselves: “How might we design a simple experience around a possibly complex process?” Open Banking reaches into a customer's own bank: consent screens, redirects and verification steps that all happen outside Pleo.

We explored ways to keep that machinery out of sight, holding the customer on a single, confident path from deciding to top up to watching the money land, so the complexity underneath never became theirs to manage.

Open Banking top-up
Choosing an amount and the bank to top up from.
Open Banking flow
Confirming through the bank and landing back in a funded wallet.

Outcome, impact and challenges

Open Banking quickly became a default way to fund a wallet: faster top-ups, higher retention, and fewer declines.

35% of all top-ups in the UK and 57% in the Netherlands are now Open Banking transactions. Repeat Open Banking customers saw 90% retention and fewer declines than customers who hadn't adopted it.

But two challenges remained:

  • An admin always has to remember to make a transfer.
  • Open Banking was only available in 2 markets.

Both came down to the same thing: a top-up still depended on someone remembering to make one. The next bet was to take that person out of the loop.

Bet 2 — Automate the wallet

Auto Top-up, Direct Debit & VRPs

Open Banking made top-ups faster, but they were still manual: someone had to remember to make one. The second bet was to remove that step entirely and let the wallet keep itself funded.

Instead of prompting an admin, Auto Top-up watches the balance and pulls funds automatically the moment it runs low, so a forgotten transfer can never decline a business-critical payment.

How Auto Top-up works

You pick a threshold and a top-up amount. The moment your balance drops below it, say under £500, we pull your chosen amount (say £1,000) from your bank by direct debit, so your team keeps spending without running dry. You can also schedule a fixed top-up weekly or monthly.

Balance dips below threshold
Auto top-up
Funds pulled

Triggered the moment your balance crosses the threshold you set.

Collaborating with engineering

Auto Top-up was only as reliable as the rails beneath it: Direct Debit integrations with Bacs in the UK, Autogiro in Sweden, Mastercard in Denmark, and SEPA across the rest of Europe, all of which I led the designs and redesigns of.

Every scheme behaved differently, so I worked closely with engineering to define the API: what data each flow needed, and how a top-up should behave when a mandate was pending, a pull failed, or a refund was in flight. Designing the model alongside the rails kept the surface simple.

Design explorations

Designing Auto Top-up meant making something that runs quietly in the background feel trustworthy: clear thresholds, transparent mandates, and obvious states when a pull is pending or fails.

Auto Top-up: setting a balance threshold and top-up amount
Setting a threshold and top-up amount.
Authorising a recurring Direct Debit mandate
Authorising a recurring mandate.
The wallet with Auto Top-up active
Auto Top-up, active in the wallet.

Outcome, impact and challenges

Auto Top-up took off, widely adopted, with insufficient-funds declines down and spend up across every market.

Auto Top-up reached over 45% of companies in launched markets. For those who enabled it, insufficient-funds declines fell by up to 50%, and spend rose 90–150% across markets.

But Direct Debit is slow:

  • 8–10 days for Direct Debit settlement in the UK.
  • 4–6 days for Direct Debit settlement in Europe.

Waiting days for funds to land undercut the whole promise of a wallet that never runs dry, which is what pushed us to VRPs.

Introducing Variable Recurring Payments

VRPs leverage Open Banking and let users authenticate once, then make future payments without additional authentication, with near-instant settlement instead of waiting days.

I designed the one-time consent flow, the limits and controls that make handing over recurring access feel safe, and the states for when a payment is in progress, fails, or a mandate needs renewing.

I also reused the same components as Open Banking, reducing engineering time and complexity.

The one-time VRP authorisation flow: authenticate once, then future top-ups settle near-instantly
The one-time VRP authorisation flow.

Outcome and Impact

VRPs replaced Direct Debit in the UK for about 80% of our customers.

Bet 3 — Introduce credit

Pleo Reserve

VRPs had solved the speed problem in the UK, but across the rest of Europe top-ups still ran on Direct Debit. Funds could take four to six days to settle, so a wallet could still run dry while money was in transit.

We had a strong feeling that credit could close that gap. But before designing anything, we needed to know which problems were actually worth solving.

User research

We surveyed 10,542 Pleo admins, a random sample across every market and size, then ran deeper interviews. Two fundamental problems emerged.

The problem space

Insufficient funds in the wallet. Admins kept hitting declined transactions when the wallet ran low, from delayed top-ups, unpredictable spend, or simply not enough cash to fund it. That constant fear of a low balance held Pleo back from becoming a company's main spending platform.

Insufficient funds in general. The SMBs we serve often have unmet financing needs. Banks are slow, opaque and expensive, and many still come up short, receiving some or none of the funding they need.

Aligning stakeholders around one bet

I collaborated with another designer to run a series of stakeholder alignment workshops and story maps, working through both problems with product, risk and commercial teams.

We chose to start with cash flow in the Pleo wallet. It was the more tractable of the two: it built directly on the wallet and Auto Top-up rails we already had, it tied to a metric we were already moving (insufficient-funds declines), and it could ship as a contained bet rather than a full lending product.

Solving financing in general meant credit risk, regulation and underwriting we weren't ready to take on, so we treated the wallet buffer as the first, lower-risk step toward it.

That led us to an "overdraft" MVP: a small, pre-approved buffer that keeps spending alive while a top-up settles.

Story mapping the credit MVP

What we built

For customers on Auto Top-up, we added a pre-approved buffer: when the wallet runs dry while a top-up is settling, they can keep spending into a small negative balance that repays itself.

Wallet hits zero. When the wallet runs out and a top-up is still settling, spending would normally stop.

The result is fewer declined transactions due to insufficient funds: a buffer that keeps spending alive while money is on its way.

Design explorations

Designing Pleo Reserve meant making a credit line feel safe and predictable: clear limits, a transparent repayment schedule, and no surprises when the wallet dipped negative.

The Pleo Reserve offer: a pre-approved credit limit, with activation tied to your Auto Top-up threshold
Setting up a credit limit.
Reserve in Auto Top-up settings: spend beyond the wallet balance while a top-up transfer is in progress
Dipping into the pre-approved buffer.

Impact and Outcomes

In Germany, insufficient-funds declines fell 75% in the two months after activation; in Sweden, 86%. Across the whole programme, between May 2023 and January 2024, declines dropped from 9.4% to 6.3% of transactions.

In summary

Looking back

Over two years, we turned wallet funding from a manual operational burden into an automated system. Faster funding, automatic top-ups, and credit buffers reduced insufficient-funds declines from 9.4% to 6.3% while helping customers spend with greater confidence.

What it meant in revenue

Fewer declines didn't just improve reliability for customers. Because Pleo earns revenue when customers spend, recovering failed transactions translated directly into business impact.

1 in 32

failed transactions recovered

€60M+

in recovered card spend

€1M+

in interchange revenue alone

What went wrong

  • Automated too early. Auto Top-up shipped on slow Direct Debit, so the wallet could still run dry; VRPs and credit were partly fixes for that gap.
  • Open Banking reached the wrong tail. Two markets at launch, and adoption skewed to those already comfortable with it. We under-served the rest.
  • Running lean cost us. Long stretches without a PM or design manager meant strategy ate into craft, and some calls were slower than they should have been.
  • Credit shipped small. Pleo Reserve was a minimal overdraft. It proved demand but left the bigger opportunity untouched.

What we could have done: led with faster rails before layering automation and credit on top, and invested earlier in the customers Open Banking missed.

What I learned

  • Hold one metric. Everything laddered to insufficient-funds declines, which kept trade-offs clear.
  • Design with the rails, not on top of them. The hard problems were settlement and failure states, not the UI.
  • Ship in slices. Betas and market-by-market rollouts beat big launches.
  • Behaviour change is fragile. Systems that remove manual work outperform systems that ask users to remember.
Chapter 2

Onboarding that scales itself

Pleo was growing fast across Europe, but the growth model underneath was breaking. Sales-led onboarding couldn't scale across 16 markets, and the self-serve motion meant to replace it wasn't converting.

Onboarding was the mechanism: the one surface every customer crossed between signing up and paying.

I led the design direction for the shift from sales-led to product-led growth, turning a complex, human-assisted onboarding into a self-serve journey built around what customers came for — while keeping KYC and verification compliant in all 16 markets.

The problem

Downgrades and churn ran high. Just 14% of customers chose a paid plan after their trial, while 86% stayed on Starter.

And of that paying 14%, a further 21% dropped to the free plan within three months, with another 9% churning outright.

The onboarding behind those numbers was one-size-fits-all: every company landed on the same generic checklist, regardless of what they signed up for.

The old Get started with Pleo page: a generic setup checklist and welcome video, the same for every company
The old onboarding: the same checklist for every company.
With an average payback period of 12 months, we lost money on 70% of the customers we acquired.

The team

  • 1 designer (me)
  • 1 engineering manager
  • 1 product manager
  • 1 product marketing manager
  • 1 content designer
  • 2 frontend and 4 backend engineers
  • Sales and operations teams

Starting with why

The first step was understanding why. We ran a Customer Effort Score survey in-app from October 2021 to September 2023, collecting 1,271 responses.

Only 119 of those, 9.4% of the sample, came from customers who onboarded self-serve — hardly anyone was making it through on their own.

app.pleo.io

How would you rate your Pleo onboarding experience?

Harder than expectedEasier than expected
The in-app Customer Effort Score survey.

I also flew to Lisbon to sit in on calls with sales executives and customer success. If we were going to take humans out of onboarding, I needed to know exactly what those humans were compensating for.

Survey outcomes

Five pains came up again and again in the responses:

Wrong product expectations

leading to disappointment with the actual product

Pricing mis­interpretations

harming our trustworthiness and the sense of value for money

Faulty setup of core functions

preventing customers from realising the full value of their plan

Poor feature understanding

causing misuse or missed value

Low spender education

preventing expansion within the company

Different symptoms, same root cause: onboarding wasn't built around what customers were actually trying to get done. It set the wrong expectations up front, and the downgrades and churn followed from there.

Mapping the journey

I brought sales, customer success, product and engineering into the same room to map the journey end to end, then laid a reimagined one alongside it. The gaps stopped being abstract: everyone could see where customers stalled, where humans were quietly papering over product gaps, and where drop-off concentrated.

Lifecycle funnel in Miro: the current onboarding experience mapped end to end
The full lifecycle funnel, mapped end to end.

We instrumented every step of the map with conversion and time data, so the conversation moved from opinions to numbers. Less than half the companies that started signing up finished, and fewer than one in five made it through verification — each drop-off now had a size next to it.

Zoomed-in view of the funnel: signup, KYC and wallet steps annotated with conversion rates and completion times
Zooming in: every step annotated with conversion and time data.

One insight cut through everything else:

Neither actual user-types nor jobs-to-be-done were mapped in the product onboarding. We served a one-size-fits-all experience.

This was the turning point. Customers arrived wanting different things — cards, bookkeeping, spending control — and onboarding treated them all the same. Expectations were set wrong on day one, value arrived late or not at all, and by the time pricing appeared it felt disconnected from what anyone came for. Everything we built next came back to this.

We didn't stop at the diagnosis. On the same board, the problems became a reimagined trial and setup experience, each change paired with the metric it was expected to move — the artefact we'd later take into the room with executives.

Problems and opportunities with the current experience, a reimagined trial and setup experience, and the business impact each change was expected to have
From problems to a reimagined experience, tied to the metrics that move.

Getting executive buy-in

By now we knew what we wanted to build. But onboarding touched sales targets, support load, compliance and revenue, and every team had its own theory of what was broken. The scope was too large to take on in one go, and it wasn't a call design could make alone.

So we made the case with data. With customer-facing Pleo'ers we defined the jobs-to-be-done customers kept bringing up, then shipped a one-page experiment to test where demand actually lay.

The one-page experiment: a use-case selector in signup asking what you want to achieve with Pleo
The one-page experiment.

The experiment was a use-case selector in signup, asking every new company what they wanted Pleo for. With a 92.9% completion rate, the data spoke for nearly every new customer: cards and bookkeeping led, followed by spending, reimbursements, suppliers and savings.

That data won the room. Execs backed the direction, and the demand breakdown became our prioritisation: we sequenced the journey around the jobs customers arrived with.

Amplitude dashboard for the use-case selector: 92.9% conversion rate and the breakdown of what new companies wanted Pleo for
The demand data behind the buy-in.

Choosing our bets

The research surfaced more opportunities than we could take on. Four themes kept coming through, so they became the bets:

  • Align onboarding to customer goals
  • Guide customers to first value
  • Delay high-friction setup tasks
  • Make plan selection transparent

Going deep on the reimagined journey

With buy-in secured and the bets chosen, I went deep, rebuilding the journey one bet at a time:

Split the journey

Rather than invent a new mental model and teach it, I worked with Pleo's partner bookkeepers and companies to fit onboarding into one they already had.

The new Get started flow broke onboarding into two clear stages:

  • Start your trial
  • Explore Pleo

Each step unlocked the next, so verifying your company came before adding money, and nothing asked for trust the product hadn't earned yet.

The new Get started flow: a two-stage journey starting with the trial, with verification unlocking adding money
Get started: onboarding split into two clear stages.

Investing in your customers

I worked with cross-functional product and commercial teams to set onboarding milestones tied to the jobs customers told us they came for: try Pleo cards, explore reimbursements, set up bookkeeping.

The page built itself around each company: the milestones it showed, and the order they came in, followed what that company had selected in the use-case experiment at signup.

Each one was a small win on the way to a set-up account: activate a free virtual card, add it to your phone's wallet, buy something for work. It meant investing in customers before they paid us anything: with a 12-month payback period, activation was where the economics turned, not signup.

Explore Pleo: milestone checklists for trying Pleo cards, reimbursing expenses, scheduling payments, connecting accounting tools and inviting your team — with the cards milestone expanded to show its steps
Milestones guiding every new company to first value.

Pushing the difficult tasks to the end

Bookkeeping was our second most popular job-to-be-done, and also the highest-friction setup task — the one that most often needed a human. I delayed it, prioritising activation over completeness: better a customer spending with bookkeeping pending than one stuck in accounting setup.

And when customers did reach it, I made it a choice rather than a chore: sync your accounting system, then decide whether your bookkeeper sets Pleo up or you do it yourself.

Connect accounting tools: link your accounting system, set up expense categories, or invite your bookkeeper to help
Bookkeeping, moved to the end and made a choice.

Recommending a plan to reduce pricing issues

Much of the downgrading traced back to pricing: customers upgrading without understanding what they'd bought. In usability tests I found it's not enough to recommend a plan; customers needed to know why we were recommending it.

So the trial ends in plain sight: a recommended plan with its price and reasoning, all plans one click away, and a clear countdown of the trial days left. A confident decision mattered more than a quick conversion.

A recommended plan based on your usage: Pleo Essential with its price, a comparison link, and the reasons behind the recommendation
A recommended plan, with the why alongside it.

Where it landed

Together, the bets went after the economics we started with — losing money on 70% of the customers we acquired — at the moments the money leaked: expectations, time to value, and the pricing decision.

Just as much changed organisationally. Onboarding stopped being a sales process and became a product motion, with sales, customer success, product, engineering and leadership working from the same journey map and the same demand data.

The new onboarding was still in beta when I left Pleo, testing the bets market by market: that onboarding aligned to customer goals converts better, that activation beats completeness, and that customers who understand their plan keep it. The final numbers aren't mine to tell, but the direction had already changed.