By early 2024, the sales team was promising things the system couldn't deliver.
A thought header, isn’t it? Sales team is not to blame. I mean, if I had to beat a metric, or even a North Star, then I’d move heaven and earth for it. Though, that wouldn’t come for free. So, imagine how we, product people, were when we were handed out this mission.
Basically, client companies wanted flexibility:
To split a single contract into different parts matching how different teams (marketing, operations, finance) actually consumed services.
They wanted quarterly, semi-annual, and annual contracts.
They wanted the ability to adjust along the way.
Back then, Woba's system only knew one way to do business: single contract, monthly billing, everything mashed into one bucket.
That's when the chaos started. Sales would close a deal, send a spreadsheet to Finance, who'd run manual calculations and create system exceptions. Customer Success tried explaining to clients how it all worked. The manager dashboard showed info that didn't match the contract. And when it came time to track usage and bill, we'd often discover inconsistencies of 11% or more between what was promised and what the system recorded.
In face of these troubled times, the Business Platform squad was born with a mission: transform Woba's business model.
From rigidity to the "contract → packages → cycles" model
Before, everything revolved around a "monolithic contract" that stored all parameters in one place: how many credits, which products (workstations, meeting rooms, events), pricing, renewal dates. If a company had 5 departments and wanted different terms for each? Spreadsheet time, managed by hand (by the nail).
Wanted a quarterly package and a semi-annual one running in parallel? Required a manual exception. Needed to transfer credits from one group to another? Open a support ticket.
The squad's first move was to rethink the current structure, creating a new layered architecture:
Contract = the umbrella, the master agreement between Woba and client.
Packages = operational units tied to groups (cost centers) or company-wide.
Cycles = validity and renewal periods within each package.
Payments = installments and charges tied to cycles.
Seems obvious now, but it was literally a philosophical shift, like an evangelization.
Can I get an amen?
We weren't just adding features, we were teaching the product to "speak fluent business" the way sales sold it and finance billed it. So, yeah, patchwork realness.
The BackOffice became the engine room
We had two BackOffices running in parallel: the "old BKO" (legacy, handling historical flows) and the "new BKO" (built from scratch for the new business model). By the way, BKO is short for BackOffice. Both consumed the same backend, but the New BKO interface was designed to be instructive.
You know those moments in software where you click "Save" (floppy disk, anyone?) and pray nothing breaks? We wanted the exact opposite. We wanted the interface to show you the impact before you confirm any action, going hand in hand with the user.
Examples:
Creating a package with 12 monthly cycles? The UI builds the installment table dynamically as you type. Want to switch to quarterly? No problem, the table reorganizes on the fly.
Canceling a contract? The interface lists, in plain text, all side effects: "This will cancel 3 packages, 8 future cycles, and 2 pending payments. The 12 confirmed reservations will NOT be canceled."
Creating a package by group? The system checks if another package of the same type already exists in the same period and warns you before saving: "Conflict detected: a Meeting Rooms package already exists for the Marketing group from 04/01 to 06/30."
We called this instructive WYSIWYG: What You See Is What You Get, but with superpowers. How else do you patch the patchwork?
A strategic decision: Brazilian Portuguese as the operational language
Might seem like a tiny detail, but it's not. We decided the entire new BackOffice would operate in Brazilian Portuguese. This wasn't about linguistic preference; it was about recognizing that BackOffice users (Sales, CS, Finance, Legal) thought, spoke, and negotiated in PT-BR.
And more: we renamed "Version" → "Cycle" across all UIs. Version was too generic and confused everyone. Cycle reflected exactly what it meant in the financial model: a validity period with start, end, credits, and associated billing.
These micro-decisions added up to a huge difference. Less noise between teams, fewer reactive tickets, fewer "what does this field mean?" questions.
Shadcn/ui entered as proof of concept (and stayed)
Did you have the chance to read the Design System case? There’s one good connection between that one and this case. No, it isn’t a sequel like the Marvel Cinematic Universe. Context is provided!
Remember that proverb which said the best time to plant a tree was 20 years ago, and the best next time is now? So, I took the seed to the Business Platform squad and made it our official lab for shadcn/ui.
We had the glorious advantage of building screens from scratch, so we didn't need to migrate legacy code. We could experiment. So we adopted shadcn/ui with our custom tokens. Forms, tables, modals, dropdowns... Everything based on well-documented, accessible, and 100% adaptable components.
Plus, we wouldn’t just rely on our own developers, who were more than inclined to adopt shadcn/ui, but a worldwide community of devs who contribute to it almost daily.
Systematic view of components crafted using shadcn/ui. These were extensively used across different UIs designed for the new back-office system.
The results were immediate: iterative cycles between design and development were considerably faster compared to proprietary components. The parity between Figma and code was nearly perfect. The devs loved it, and so did I!
This felt like winning a prize! Migrating to shacn/ui was like an old grudge between the engineering and product teams, so I was really glad I made the move to advocate and encourage others to follow suit on this one.
It was so successful that in the following months, we began gradual migration in other products. But it all started here, in Business Platform.
When information density is necessary (and that's okay)
There was a crucial design moment where we had to make a tough choice. The BackOffice screens were dense. Lots of required fields. Wide tables requiring horizontal scroll. Forms with 15, 20 inputs.
Dense but necessary: every field existed for operational integrity. The solution wasn't simplification at any cost, but making consequences visible.
Could we simplify? Sure. But simplify what? Every field existed because it was necessary for operations to function. If we omitted information to "keep it clean," the error would appear elsewhere, usually in financial reconciliation or a misconfigured contract. That’s a no no for data integrity and, for obvious reasons, the whole pipeline of metrics.
So we made peace with complexity. The solution wasn't to simplify at any cost. It was to make consequences visible and language consistent.
Glossaries. Contextual hints. Inline examples ("monthly = 1 cycle/month; quarterly = 1 cycle/3 months"). Empty states that teach what to do. Error messages that don't just say "failed," but explain why and how to fix it.
Flows that became product (and freed the team from manual work)
Throughout 2024, we productized a series of flows that previously happened via spreadsheet, email, or direct database intervention:
Data import and export
Spreadsheet upload with automatic validation, error review before applying, and filtered exports. Total self-service for bulk operations.
Spreadsheet upload with automatic validation. Error review screen before applying. Export with filters by company, package, period. Total self-service.
Complete private office editing
Complete CRUD in the BackOffice for private office data (pricing, amenities, images, square footage). No more tech support tickets.
Before, editing private office data (pricing, amenities, images, square footage) required opening a tech support ticket. We created a complete CRUD in the BKO.
Commercial proposals
Sales could build proposals directly in the system: select multiple rooms, mark favorites, preview contracts, send to clients. WYSIWYG for proposals.
Sales could build proposals directly in the system: select multiple rooms, mark favorites, preview the contract, send to client. WYSIWYG even in proposals.
Upsell, downsell, and cancellation
Transforming existing contracts (increase credits, decrease, or cancel) became a guided flow with validations and clear messages about side effects.
Transforming an existing contract (increase credits, decrease, or cancel) became a guided flow with validations and clear messages about side effects.
License Fee
Fee systematized as its own entity with listing, creation, editing, and package integration. No more ad-hoc handling.
Fee that some partnerships charge for space usage. Before it was handled ad-hoc. We systematized it as its own entity with listing, creation, editing, and package integration.
Each of these flows saved hours of manual work per week. And more importantly: reduced error margin.
The numbers tell the story
Quarter over quarter in 2024, the squad hit over 70% of targets.
But there's a number I like even more: between Q4/2024 and Q1/2025, we tracked data quality in Private Office (one of the most complex products to manage). Initially, 19% of contracts had inconsistencies between what was recorded and reality.
After implementing the new business model?
✨ 1.87% inconsistencies. ✨
Manual adjustments in financial reconciliation? Dropped from 11% to 0.83%. Take that, outdated business model!
These numbers didn't appear by magic (I’ll never stop believing, though). They appeared because the rule became explicit in the product. When the BackOffice faithfully mirrors the contract → package → cycle model, and the UI teaches the rules as you use it, data is born clean.
What I learned
Explicit rule beats silent exception. Always. If the system's behavior isn't obvious from the interface, someone will make a mistake. And the mistake will appear on the wrong side of operations.
Clear precedence prevents surprises. When we have multiple possible packages for the same consumption (e.g., a company-wide package and a group package), the system needs crystal-clear selection criteria. Group > Company-wide was the rule that brought peace.
Accepting temporary heterogeneity was crucial. We kept old and new BKO running side by side while we migrated accounts. We didn't try to change everything at once. It was gradual, controlled, reversible.
Business Platform wasn't just a project. It was the re-engineering of Woba's entire business model, with the interface as the protagonist of change.