Zalando partners kept failing the banking details form, and three internal teams cleaned up after them. I redesigned it, cutting submission rejections by 70% and support tickets by 80%.
Context
Before a brand sells on Zalando, it has to tell Zalando how to pay it
Zalando's Partner Program lets brands sell directly on Zalando across 20+ markets. zDirect is the platform where those partners run their business. After signing the contract, every partner sets up a business account.
That setup includes banking details and a billing mode. The billing mode decides which currency the partner gets paid in.
I joined the Partner Lifecycle Management team and took this on from a product brief. The brief set the goals. My job was to find out why the form kept failing, and fix it.
- 1Sign the contract
- 2Set up the business account
- 3Set up logistics
- 4Deliver the ordered articles
- 5Create and send invoicing
- 6Ensure the season runs smoothly
Problem
One form, three teams cleaning up after it
Partners entered an IBAN, the international bank account number, for every single market. That one rule caused most of the trouble.
User
Partners only learned about mistakes after they were rejected
Market and currency mismatches, several bank accounts for euro payouts, typos in bank details. Partners found out only after review, through a manually written rejection note. Many still didn't know how to fix it, so they contacted Partner Care.
Business
Manual work on every submission, plus avoidable conversion costs
Master Data Management checked every IBAN by hand with an external tool. Order to Cash then guessed each partner's billing mode. Every partner on euro mode meant Zalando converted their sales at its own cost.
Impact
70% fewer rejections, 80% fewer support tickets
Partners started getting the form right the first time. The two teams doing manual review got their time back. Product management measured these after launch.
Approach
The brief set the goals. Discovery found the causes.
The product manager onboarded me with a brief: the goals, the as-is process, and the stakeholders. The goals were clear. Why the form failed was not, so I started there.
-
1
Map the review process
How does a banking details submission get reviewed, and by whom?
Enters an IBAN per market and submits
Copies each IBAN and checks it by hand
Valid? No YesRejects and writes a note by hand
Doesn’t know how to fix it, opens a ticket
Investigates and replies
Guesses the billing mode
Goes live, doesn’t know their billing mode
Answers billing questions
End-
2
Find the top rejection reasons
Which mistakes cause rejections, and why do partners make them?
-
3
Turn each finding into a question
Every finding became one "how might we" question, and every question one design decision.
Execution
Fix the cause, not the form
Step 1
Moved banking details to account level, then made the form lighter
Before, zDirect asked for an IBAN inside each market's setup. We moved banking details to the account setup, with one bank account per currency. That alone removed the market and currency mismatch, the most common rejection reason.
Iteration 1: Expandable forms
All Eurozone markets share one form. In local currency mode, each non-euro market adds one more. My first iteration made each of these forms expandable, to keep the page short for partners in many markets. It added clicks without adding value, because partners had to fill every form anyway.
Iteration 2: Open forms
The second iteration kept every form open and asked for less. Bank country went, since the IBAN already contains it.
Step 2
Turned three findings into three decisions
Finding
Order to Cash guessed each partner's billing mode from their bank details. Partners never saw it, so they asked Partner Care how they were paid.
How might we
Remove the guessing and let partners decide?
Decision
I put both billing modes in the form and explained who converts currency and who pays for it. Local currency mode pays each sale in the currency the customer paid in. It was preselected and labeled Recommended, because it avoids conversion costs. Partners could still choose euro mode.
Finding
Partners made typos in bank name, bank country and bank identifier code. For EU banks, all of this can be read from the IBAN.
How might we
Stop partners typing what the system already knows?
Decision
Once a partner enters the IBAN, the bank name fills in. Account holder fills in from Zalando's legal entity data. Both are read only, so partners can double check without retyping.
Finding
Master Data Management copied every IBAN into an external tool to check it. When one failed, they wrote a rejection note by hand and waited.
How might we
Catch errors before anyone has to review them?
Decision
I added IBAN validation at input, plus an error for IBANs outside Zalando's markets. The rejection moved from the review queue to the moment of typing.
Step 3
Designed for partners after onboarding too
Partners don't fill this form once. They set up, expand into new markets, and change their minds while live. I designed each of those states.
-
1
Onboarding
Choose a billing mode and add bank details.
-
2
Expanding
On local currency mode, add an account for the new currency. On euro mode, nothing changes.
-
3
Live
Switch billing mode, with a confirmation that explains what changes.
Setting up details
Onboarding and expanding
Changing billing mode
Live operations
I also designed the internal tool where Master Data Management reviewed the same data, organized by company and market.
I worked closely with the product manager, shared progress with engineering, and ran feedback rounds with the design team.
Key insights
Make the cheaper option the easy option
Euro mode was simpler for partners: one account, nothing to add when expanding. But it cost Zalando money. A sensible default, a clear label, and honest copy about who pays moved partners the other way.
Learnings
Design for the lifecycle, not just the first visit
Partners move through onboarding, expansion and live operations, on two surfaces. Treating all of that as one scope was the right call.