Role
Senior Product Designer - Freelance
Client
Mobilitas s.r.l.
Timeline
Feb 2024 - Present
Designing the digital operating system for a growing e-bike rental and experience business
From a booking plugin and spreadsheet system to a live platform that the business runs on today
The challenge
Mobilitas had grown from a simple e-bike rental operation into a multi-location business with guided experiences, wine tourism packages, hotel partnerships and group events. Every booking was still managed through a WordPress site with a plugin originally designed for hairdressers, plus WhatsApp messages and a shared spreadsheet. When demand started growing, the system couldn't keep up.
What I did
I designed and built the complete digital infrastructure of the business — from the customer booking experience and partner collaboration flows to internal operations, automated communications and the full analytics stack. I was the only person responsible for all digital product work, working alongside the CEO and a customer success manager.
The outcome
The business went live on Odoo in June 2024. In the first fully tracked season (June–October 2025), the site reached 4,000 active users — 3,700 of them new — with an average engagement time of nearly 2 minutes. Bookings grew from 1,150 in 2024 to 3,400 in 2025, a 196% increase year on year, with the same team of three people. The Google Business Profile reached 129 reviews at 5.0 stars. The business now runs on a system it didn't have to build from scratch every season.
The goals
Business goal
Replace a fragmented, manual operating model with a digital system that could handle growing booking volumes, multiple product types, partner collaborations and operational complexity — without requiring the team to grow proportionally.
Customer goal
Customers needed a clear, trustworthy way to discover and book e-bike rentals and guided experiences online — understanding exactly what was included, where to go, what happened in bad weather, and receiving the right information at the right moment without having to call or message.
The problem space
The surface problem was a booking plugin that wasn't built for rentals. But the real problem was deeper: every part of the business was disconnected. Bookings didn't trigger operational tasks. Partners had no structured way to collaborate. There was no visibility into which products or channels were actually driving revenue.
Niche e-bike rental tools could handle bookings, but nothing more. Mobilitas needed one system for experiences, gift cards, events, partner invoicing, inventory and CRM. That's what made Odoo the right choice — and the hard part wasn't choosing it. It was configuring it from scratch while the business was already running, knowing that every decision about product structure and data architecture had consequences for everything built on top of it.
What success would look like
A live booking system that reduced manual coordination, enabled partner-driven bookings without backend access, and helped validate the experience through reviews and returning customers.
Process highlights
Replacing the old system without breaking what was working
Before Odoo, Mobilitas used a WordPress site with Booknetic — a booking plugin designed for hairdressers that I had adapted for e-bike rentals. It was a creative workaround, but it was fragile. Manual bookings came in via WhatsApp and were tracked in a spreadsheet alongside the online ones.
Key decision - choosing Odoo over niche rental tools
The bike rental tools I evaluated were good at managing rentals, but that's all they did. Mobilitas needed one system to run the entire business: invoicing, CRM, inventory, website, email automations and reporting. Odoo could do all of that. The trade-off was complexity — Odoo required significantly more configuration — but it was the right bet for where the business was going.
Designing the product and category architecture
Before designing any flow, I structured how products and categories worked inside Odoo. This was the least visible part of the project and the most consequential. If the data structure was wrong, every report, automation and partner flow built on top of it would be unreliable.
I created categories for different product types: B2C rentals, guided experiences, gift cards, events, accessories, inventory bikes per location, and partner-specific products. Each partner reseller got their own product variants with dedicated discount codes, so that their orders could be filtered and invoiced automatically at the end of each month.
Key decision - treating the product structure as the foundation of everything
Every automation, report and partner flow depended on how products were categorised. I spent significant time on this before touching any customer-facing design. A reseller's monthly invoice, a filter for "bikes rented in August", an operational reminder about morning vs afternoon slots — all of these worked because the product categories were structured correctly from the start.
475 products configured in Odoo, structured by category to enable filtering, reporting and automation downstream.
Designing three partner collaboration tiers
I designed a three-tier collaboration model — Courtesy, Partner Attivo and Reseller — each with a different commercial relationship, booking flow and tracking mechanism. For Reseller partners, orders are filtered automatically in Odoo and invoices generated monthly without manual reconciliation. Mobilitas currently has 20 active partners.
Courtesy
the partner promotes Mobilitas via QR code or dedicated link. Customers book directly. Zero commission, zero admin for the partner.
Active Partner
the partner sends customers through a tracked link. Mobilitas handles payment and invoices the partner 15% commission monthly.
Reseller
the partner sells the experience themselves and invoices the customer directly. Mobilitas invoices the partner at the end of the month at a discounted rate, tracked automatically via Odoo filters.
Setting up analytics and growth infrastructure
I implemented GA4, GTM, Google Ads and Meta Ads with conversion tracking and consent mode from the start. In the first tracked season, paid and organic search were almost equally balanced — a sign the SEO foundation was starting to work. I also set up a post-rental email flow for Google reviews and designed NFC cards for in-person collection.
Traffic acquisition breakdown from the first full season — paid and organic search almost equally balanced, with a 66% engagement rate across 7,000 sessions.
1,150->3,400 rentals in one year
The customer-facing booking flow for an experience — connected directly to Odoo inventory, availability and post-booking communication logic.
The Odoo system went live in June 2024 — at the start of the high season, with no soft launch. Everything had to work from day one.
The first full season validated the core decisions. Standard bookings ran without manual intervention. The team could filter orders by location, product type and partner. Reseller invoices were generated automatically at the end of each month.
In 2025, the second full season on the platform, bookings grew to 3,400 — nearly three times the volume of the year before, on the same system, with the same team of three people.
rentals in 2025
196% increase from 2024
June–October 2025, 66% engagement rate
Reflections
Check the live website
The hardest part wasn't the design — it was the sequencing. Every decision about product structure, category naming or email logic had consequences for things built weeks later. Getting that foundation right before touching anything customer-facing saved significant rework mid-season.
Iterative feedback replaced formal testing. There were no structured user testing sessions on this project. Feedback came from GA4 behaviour, operational friction flagged by the team, and customer reviews. In retrospect, even one or two structured sessions with first-time bookers early on would have helped — particularly around the checkout flow, which I didn't design (standard Odoo) but could have influenced more.
Measuring impact was harder than building the system. The conversion tracking had implementation challenges in the first season, so some GA4 data isn't fully reliable. This became a design problem in itself — you can't optimise what you can't measure. Rebuilding the tracking layer properly was one of the most valuable things I did in year two.
What I'd do differently. I'd push for a simpler partner tier model at the start — three tiers launched simultaneously created a lot of configuration work before we knew which tier partners actually preferred. Starting with one and adding complexity based on real partner behaviour would have been faster and smarter.
What's next. The 2026 plan points toward deeper partnerships with tour operators and accommodation providers as the main growth lever — moving from a local rental business toward a broader experience platform, with the Langhe as the primary focus and Pragelato as a seasonal addition. The digital infrastructure is designed to support that: more partner pages, more product types, more locations — without rebuilding the system.
How we measured success
Before the new system, there was no way to measure anything meaningful. Success in year one meant the system running without manual intervention and the team having operational visibility they'd never had before. In year two, with GA4 and GTM properly configured, we could track traffic sources, funnel behaviour and booking patterns for the first time. Paid and organic search were almost equally balanced — a sign the SEO foundation was starting to work. Conversion tracking had gaps in year one that took time to fix; resolving that became a design priority in itself.