WEP: a global e-commerce for study experiences abroad
Turning a travel catalogue into a machine for shaping experiences around the person.
The problem
No family decides in an afternoon to send a child to the other side of the world for ten months. The decision matures over weeks, passes through a consultant who asks questions, changes shape when the grandmother asks whether it is safe and when the teenager finds out that in New Zealand you surf before school. It is a long conversation, and the portal hosting it was a grid of filters: country, duration, price.
WEP needed to put that conversation back inside the site. Not to sell more through the same machinery, but to change the opening question: not which programme are you looking for, which assumes you already know, but what do you want to happen to you. Together with Fightbean, who led the design, we rebuilt the platform around discovery instead of around the catalogue.
How we solved it
Navigation starts from goals and dispositions and arrives at the programmes, not the other way round. Recommendations take account of what the person has said and of how they move between pages. Every destination carries a story explaining what it is like to live there, rather than a list of available cities. And the consultant stays inside the journey, because on a decision this size nobody wants to be left alone with a button.
A catalogue answers people who already know what they want. Everyone else needs somebody to ask the first question.
The architecture had to hold something less visible but no less binding: WEP is a distributed organisation, and its offices update content at the same moment from different time zones. Next.js with Incremental Static Regeneration keeps pages static and instant while the catalogue changes underneath; DatoCMS lets editorial teams work in parallel; the multi-environment setup on Vercel lets simultaneous deployments coexist without conflicts and without downtime windows.
The rest was deciding what not to rewrite. Quotes and payments were already handled by a backend that worked: we built a custom integration on top of it instead of rebuilding it. Leads generated by the discovery journey land in ZOHO, where the sales team already worked. The new platform grafted itself onto the existing processes rather than replacing them.
The results
The last number is the one that says the most. Fewer support requests at the same traffic means the questions a person used to answer on the phone now find their answer earlier: whoever reaches the end has already understood what they are buying. The consultant has not been taken out of the picture, they have been freed from the easy questions.
A TypeScript and Next.js front end, with Incremental Static Regeneration to keep pages static and fast over a catalogue that never stops changing, Redux for application state and Tailwind for the interface. DatoCMS is the headless CMS, set up for editorial teams writing in parallel from different countries, and Vercel handles deployment and CI/CD with native ISR support and separate environments for each team. Two custom integrations close the loop: the ZOHO APIs, to carry leads into the CRM already in use, and a bridge to the existing backend, which goes on handling quotes and payments without being rewritten.
A TypeScript and Next.js front end, with Incremental Static Regeneration to keep pages static and fast over a catalogue that never stops changing, Redux for application state and Tailwind for the interface. DatoCMS is the headless CMS, set up for editorial teams writing in parallel from different countries, and Vercel handles deployment and CI/CD with native ISR support and separate environments for each team. Two custom integrations close the loop: the ZOHO APIs, to carry leads into the CRM already in use, and a bridge to the existing backend, which goes on handling quotes and payments without being rewritten.
Got something similar in mind?
Tell us what you want to build and we will help you find the shortest way there.
