By early 2024, the sales team was promising things the system couldn't deliver.
Companies wanted flexibility. They wanted 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. And 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.
Facing this impasse, the Business Platform squad was born with a mission to transform Woba's business model.with a mission to 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. 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. We weren't just adding features, we were teaching the product to "speak the business" the way sales sold it and finance billed it.
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). Both consumed the same backend, but the New BKO interface was designed to be instructive.the same backend, but the New BKO interface was designed to be instructive.
You know those moments in software where you click "Save" and hope nothing breaks? We wanted the opposite. We wanted the interface to show you the impact before you confirm any action.
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.
A strategic decision: Brazilian Portuguese as the operational language
Might seem like a detail, but it's not. We decided the entire new BKO 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)
Remember the Design System from the previous case? Well, the Business Platform squad was our official lab for shadcn/ui.
We had the 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.
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!
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 BKO 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.
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 model?
1.87% inconsistencies.
Manual adjustments in financial reconciliation? Dropped from 11% to 0.83%.
These numbers didn't appear by magic. 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 (and where we're going)
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.
And the next step? We're evolving Credit Transfer (predecessor to "cycle advance") to give even more autonomy to the Manager. Consolidating License Fee as a complete module. And restructuring Private Office to unify data and metrics in one place.
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.of Woba's entire business model, with the interface as the protagonist of change.