Control Tower 2.0 / Internal operations platform / Retool → React migration / Case study

Product design · IA & interaction

Six tools. One record. A platform rebuilt from the information up.

Control Tower is the internal platform every Ritchie Bros. support team uses to move a transaction from auction to payment to released asset. I audited 51 real support actions, consolidated six fragmented tools into one Unified Customer Record, and led product definition and design through to moderated user testing and engineering handoff — including the strategy shift from a big-bang launch to a blended, replace-as-you-go rollout.

Role: Product Designer — IA, interaction & product definition
Team: 2-person design team · design-led product definition
Scope: 6 tools → 1 UCR · 7 user types
Status: Tested with 7 support users · in build
Tools: Figma · HTML prototypes · SOP audit

01The product

A control tower for every transaction

Ritchie Bros. runs one of the world's largest marketplaces for heavy industrial equipment. Behind every sale is a chain of people making sure it completes: Customer Care Agents answering buyer and seller questions, CSMs managing relationships, Fin Ops reconciling money, Lien Specialists clearing titles.

Each of them lives in Control Tower — the internal tool that lets them see and act on what's happening across an account. The name is the right metaphor: like air-traffic control, the job is keeping many moving things coordinated and intervening at exactly the right moment.

This project was the 2.0: a migration off a low-code Retool build onto a purpose-built React application — and the chance to fix the structure, not just the surface, before the Retool contract ran out.

02The problem

A tool that grew, not one that was designed

The Retool version had been built feature-by-feature, in response to whatever request came in next. It worked — but the structure underneath had never been designed, and the customer had been split across six separate tools. The cost showed up in the day-to-day:

Fragmented

One customer, six tools. Resolving a single issue meant hopping between disconnected tools, each holding one piece of the picture and none holding the whole.

Redundant

The same data, re-entered and re-found. Contact details, registrations, and notes lived in multiple tools at once — with no guarantee they agreed.

Role-blind

Built for no one in particular. A Fin Ops reconciliation and a Care Agent's quick lookup were served by the same flat, undifferentiated interface.

Inconsistent

No shared patterns. Similar actions behaved differently depending on where you found them, so the tool had to be re-learned screen by screen.

Ownership

The product question needed an owner. Through discovery and definition, I took on the PM function alongside design — setting requirements and deciding "what should this even be" so the work had a home from day one.

03The audit

Start with the work, not the screens

As the designer who was also setting the requirements, I could have started sketching layouts. Instead I started with an audit. I went through the support teams' standard operating procedures and eLearning courses and pulled out every discrete thing a user actually does in the platform — 51 distinct actions in all.

Each action was mapped to the roles that perform it, the data it touches, and the legacy tool it currently lived in. That library became the source of truth for everything that followed: the platform's structure fell out of the work instead of being imposed on it — and it exposed just how much of the "six tools" was really one job, scattered.

STEP 1

Capture

Catalogued every discrete action available in Control Tower today, straight from the SOPs and eLearning material the teams actually train on.

STEP 2

Group

Clustered related actions into capability areas — account management, financial transactions, asset & pickup — to find the natural seams.

STEP 3

Map to roles

Matched every action to the user types that actually perform it, from search-first Care Agents to queue-only Approvers.

51SOP actions audited & mapped to role, data, and legacy tool

6→1Fragmented tools consolidated into the Unified Customer Record

7User types mapped — each with its own entry point & action set

The full audit action map: 51 actions organized by seven user types — Customer Care, CSM, Finance/AR, Approver, Yard Staff, Sales field, and Sales Support — color-coded by capability area with entry points and external-system handoffs marked — **The audit artifact itself** — every action, by user type, color-coded by capability area, with each role's entry point and external-system handoffs marked. This one map is the requirements document the architecture was built from. Click to zoom.

04The re-architecture

Six tools, condensed into one record

The audit's clearest finding: most of those tools were views of the same customer. So the centerpiece of the new architecture is the Unified Customer Record — search once, and get the whole account in a single, navigable place. Every legacy capability was mapped to its new home at the action level, so nothing is lost in the move and nothing has to be built twice.

Account Supportcontacts · orgs · T&Cs

Event Registration Supportregistrations · bidding

Buyer Dashboardbuyer standing

Refund Managementrefunds · credits

Hold Managementholds · releases

Customer Notesnotes · activity

Unified Customer Record

One search, the full account. A three-layer page — sticky identity header, section navigation, scrolling content — so the user never loses whose account they're in, no matter how deep they go.

OrganizationsRegistrationLotsInvoicesPaymentsNotes & ActivityT&C

/01

Home

Role-specific landing. What a Care Agent needs first is not what Fin Ops needs.

/02

Events

The work queue — where a support user's day begins, and incoming items get triaged.

/03

Unified Customer Record

The flagship surface. Six tools' worth of customer context, one searchable record.

/04

Payment Management

Shared by Fin Ops and support, organized into task-scoped subsections.

/05

Asset Support

Everything tied to the equipment itself, from the support side of the lifecycle.

/06

Adjustment Requests

Corrections and exceptions, with approval as an access level, not a separate role.

05The strategy shift

From "ship it all at once" to a blended experience

The original mandate was a big-bang launch: rebuild everything, then cut over in one move. As the architecture took shape, I pushed a different conversation — about risk, about the Retool contract clock, and about what support teams could actually absorb.

The outcome was a blended experience: CT 2.0 replaces the highest-traffic legacy tools first, inside the platform users already work in, while the rest follows on the same architecture. Because every capability had already been mapped in the audit, re-sequencing the rollout cost nothing — the structure was built to be released in slices.

The original plan

One launch, everything at once

Full parity across every legacy tool before anyone touches the new platform. Maximum build time before any user feedback, maximum cutover risk, and every month on Retool still on the bill.

Where I landed it

Replace the core, blend the rest

The first release replaces three legacy tools outright — the surfaces support touches most, rebuilt with full capability parity plus the redesigned search:

Account Support→ UCR Account tab
Event Registration Support→ Account · registrations
Customer Notes & Activity→ Notes & Activity tab

Why this mattered beyond the schedule: shipping a real slice early means the design system, search model, and record structure get validated by daily use before the remaining tools migrate onto them — so the foundation is proven, not projected.

06Deep dive · first release

Search & Account: where the impact concentrates

Search and the Account tab are the front door of the UCR — the surfaces every role touches on nearly every task. They're where the six-to-one consolidation stops being an architecture diagram and becomes something a Care Agent feels on the next call.

06.1

One search surface, built for how identifiers actually behave

Every state designed — from first keystroke to "no customers found."

Scoped, composable search

One field, scoped by chips — email, name + company, sale #, buyer #, owner code. The scope makes the query unambiguous before it's run, instead of guessing at intent afterward.

Inline disambiguation for numbers

Numeric identifiers are the ambiguity hot spot: a sale number can mean the sale, its buyers, or its sellers. Search resolves this inline — surfacing "buyers in this sale" and "sellers in this sale" as distinct, labeled result groups instead of a flat mixed list.

Fuzzy where it helps, strict where it must be

Names and companies match forgivingly; identifiers match exactly. The user gets speed on the human fields and certainty on the system ones — which is what pulling up the right customer under time pressure requires.

Designed empty & error states

"No customers found" is a designed moment with a clear next step, not a dead end — and success, error, empty, and business-rule states are specified for every flow so engineering never has to invent one.

Progression of Control Tower 2.0 search states: empty search, email search, name search with results, name and company, sale number with buyer and seller disambiguation, and the no-results state — **The full state progression** — scope selection, results by email, name, and sale #, buyer/seller disambiguation on numeric identifiers, and the designed no-results state. Click any screen to zoom.

06.2

The Account tab: full parity, better structure

Everything Account Support and Event Registration Support did — reorganized around the customer instead of the tool.

A multi-org customer model

One person can act for several organizations. The record models that directly — organizations, contacts, and cautions per org — with a persistent scope chip that filters the whole record to one org without losing the person.

Registrations in context

Event registrations live on the account with bidding details, deposits, limits, and cautions inline — grouped by organization, so "why is this bidder blocked" is answered on the same screen that can fix it.

Drawers as the action surface

Edit contact, register to sale, add to account — every action opens in a consistent drawer or focused dialog, with modals reserved for high-consequence confirmations. One pattern to learn, everywhere.

An audit trail by default

Terms & Conditions history, edit provenance, and activity share one shared audit pattern — so trust in the record is built into the structure, not bolted on per feature.

The org-scoped record: the scope chip filters the record to Acme Solutions, showing that organization's account details and contacts, with the register-to-sale panel open against the scoped account — **The org-scope filter, applied** — the persistent scope chip filters the whole record to one organization without losing the person; here with the register-to-sale panel open against the scoped account. Click to zoom.

Register to sale drawer showing account selection, sale number search with ten results, and the selected sale state ready to register — **Register to sale** — pick the account, search the sale, select, register; blocked registrations explain themselves with the caution that caused them. Click to zoom.

Examples of specified success, error, empty, and business rule states across the account flows — **Every state, specified** — success, error, empty, and business-rule examples shipped with the designs, so the handoff covers the unhappy paths too.

06.3

The refined record — what engineering is building

The surfaces handed to the development team, refined through prototype testing and design reviews.

Focused tabs, capabilities intact

The account surface resolved into dedicated tabs — Organizations, Registration, Lots, Invoices, Payments, Notes & Activity, T&C — each carrying its legacy capability set forward under the same persistent identity header.

Tables the legacy tools couldn't offer

Grouped column headers, configurable table settings, bulk selection, and running totals — the richer search, sort, and filtering the Retool build could never support becomes standard across every tab.

The refined Organizations tab: one customer with membership across multiple organizations, each with account details, contacts, cautions, and Salesforce links under a persistent identity header — **The Organizations tab** — one person, multiple organizations: account details, contacts, and cautions per org, with membership always visible at the header. The multi-org model, made concrete. Click to zoom.

The refined Registration tab showing event registrations across organizations with bidding details, deposits, bid limits, approval status, and org cautions in one table — **Registration in the record** — registrations across orgs with bidding details, deposits, limits, and approval status inline. Click to zoom.

The refined Lots tab with grouped column headers for lot info, event, and fees, configurable table settings, bulk actions, and running totals — **The Lots tab** — grouped columns, table settings, bulk actions, and running totals in one working view. Click to zoom.

06.4

The impact, on both sides of the ledger

Better for the people in the tool. Cheaper for the business running it.

For the support user

One search instead of six entry points. Any identifier a customer reads over the phone resolves to the right record from a single surface.
The wrong-record risk designed out. Inline buyer/seller disambiguation on numeric IDs removes the most common way agents landed on the wrong account.
Answer and action on the same screen. Registrations, cautions, contacts, and history sit together — resolving an issue no longer means reassembling the customer from parts.
One interaction language. Consistent drawers, states, and audit patterns mean the tool is learned once, not screen by screen.

For the business

Retool licenses retired on schedule. Replacing the highest-traffic tools first converts the migration deadline from a risk into a savings line.
Nothing built twice. Capability-level mapping from the audit means the phased rollout produces zero throwaway work.
Shorter handle time by structure. Fewer tools per task and fewer wrong-record recoveries compound across every call the support org takes.
A reusable foundation. The search model, record structure, and pattern library are the starting point for every internal tool that follows — not a one-off.

07Validation

Tested before it ships

The designs were pressure-tested continuously on the way here — director-level architecture reviews, working sessions with engineering, and interactive HTML prototypes with real data in front of support team members. Then came the formal round: seven moderated, task-based sessions with a mix of Customer Care and CSM team members, run against the interactive prototype.

Observed, not told. Rather than pitching the benefits of the new tool, participants worked through real tasks — finding customers across identifier types, registration and caution scenarios, org-scoped workflows — while we watched what worked, what confused, and what they'd change. The synthesis traveled with the designs into the engineering handoff, so the build scope reflects what real users did, not what we hoped they'd do.

7Moderated task-based sessions with support team members

2Roles in the mix — Customer Care agents & CSMs

3Task families — search & identify · registrations & cautions · org-scoped work

08The handoff

In engineering's hands

With testing complete, I brought the results and the refined Unified Customer Record to the development team — a working session to align scope, surface open questions, and set build sequencing ahead of the formal handoff at the end of August.

Phase 1 ships to the support org first: Search, the Account surfaces, Event Registration, and Notes replace their legacy tools outright, while Finance and Operations continue on today's tools until their sections migrate onto the same architecture — the blended rollout, exactly as designed.

PresentedTest synthesis + refined UCR designs, for development review

AlignedBuild scope, open questions & sequencing

NextFormal dev handoff · end of August · support org first

09The bigger picture

Initiative one of a unified back office

Control Tower 2.0 is the first initiative of a larger ambition: a unified back office — one coherent experience across the internal tools that run the business. And it establishes the operating model for getting there: design sets the experience, and the design foundation, before the tools are built.

The audit method, the record structure, the search model, and the pattern language weren't made for one platform. They're the foundation every internal tool that follows will inherit — which is exactly why getting this first one structurally right mattered more than shipping it fast.

The experience

One way to find a customer, one record to act on — a mental model that holds across tools, so moving between them stops costing context.

The foundation

Patterns, semantics & states as shared infrastructure — drawers, audit trails, the five-color semantic system, and specified states, reusable by every team that builds next.

The method

Audit the work, then architect — a repeatable, evidence-first way to consolidate any cluster of internal tools without losing a single capability.

10Reflection

Owning the whole question

The thing I'm proudest of isn't a screen — it's that the structure holds up under change. When the mandate flipped from "ship it all at once" to a blended rollout, nothing had to be redesigned; the audit-driven architecture was already built to release in slices. That's the payoff of starting with the work instead of the screens.

Taking on the PM function through discovery and definition meant owning the product question as well as the design one — what this should be, when it should ship, and what it sets up next, with product management picking up the delivery-to-production handoff. Steering the rollout strategy, not just the interface, is the part of this work I most want to keep doing.