02 — About
Context
Before a company can send tax-compliant e-invoices from NetSuite, someone has to connect three systems: NetSuite, Oracle Business Network (OBN) and Avalara. That setup is done once per account and again per subsidiary, usually by an implementation specialist or the customer's own IT team.
The Problem
The setup felt like one task but was spread across 5 separate areas of the product, with prerequisites that were never stated. Users switched roles four times to finish it, couldn't tell what was done or blocked, and almost all new customers needed a support session to complete it
Role
User Experience Designer
Domain
Finance & Compliance Configuration
Team
1 UX Designer, 1 Product manager, 10 Developers
Timeline
4 months
Status
Shipped (2nd Phase)
Impact
72%
Fewer setup-related support requests
35%
fewer clicks to complete setup
30%
faster setup completion
03 - Current Flow
How setup actually worked
The team wanted to understand why customers couldn't finish setup alone, so I mapped the full path from a new account to a subsidiary that can send compliant invoices. It crossed five areas of NetSuite, two external systems and two different user roles.
Every stage returns the user to navigation to find the next one, and every switch between Oracle Business Network and Avalara means changing role to continue.
Where it broke, screen by screen
After mapping the flow, I reviewed the key screens users interacted with, to find where the experience became unclear at screen level.
Navigation Entry Points
Related setup actions were placed across separate navigation areas, making it difficult for users to understand where the setup journey started and how the steps connected.
Oracle Business Network (OBN) Registration
Users could select a subsidiary for registration, but the dependency between parent registration, child subsidiary availability, and authorization was not clearly communicated.
Avalara Provisioning
The Avalara provisioning screen required users to verify information across systems, but field differences between NetSuite, OBN, and Avalara created additional manual effort.
5
Areas of the product
one setup crosses
4
role switches to
finish one setup
15–20
subsidiaries per account,
each needing its own setup
Setup runs once per subsidiary, by the same admin, 15 to 20 times for one account.
04 - Evidence
How I knew this
The evidence came from three places, none of them a formal study. I've named each one and what it could and couldn't tell me.
Product Manager
Input across the project on where setups stalled, which steps generated the most questions, and the support load sitting behind them. This is where the scale of the problem came from.
Customer Success Team
The people who walk customers through setup, across many accounts. They knew which steps generated the most questions & where setups stalled most often breadth no single customer could give me.
My Own Heuristic Review
I walked the full setup path across the live screens myself, recording every point where the next step wasn't discoverable from the current one. The current-state map came out of this.
The third is the only one I ran myself, and it's where the map came from.
Who I was designing for
Built from PM and support input rather than interviews
I built personas for
Company IT team/Admin
NetSuite Implementation Specialist
External Implementation Consultant
The gap that mattered was consistent across all three: each expected setup to be one task, and each hit a different point where it turned out not to be.
What I couldn't see
I didn't speak to customers or implementation specialists directly. My closest source was the Customer Success team, who know this setup well which means they see the pattern across accounts, but they no longer experience it as someone doing it for the first time. The first-run confusion was reported to me, not observed.
05 - Framing
The obvious solution wasn't available
Setup runs 15 to 20 times per account, so the first instinct is to batch it. That isn't possible: data privacy rules and the integration architecture both rule out setting subsidiaries up together, so each one registers on its own.
The constraint
No bulk setup, no templating, no duplicating a completed subsidiary. That removed the solution every designer reaches for first.
What it left me
If the number of runs is fixed, the only levers are the cost of each run and how well someone can navigate the sequence across all of them. That chose the design: a guided path through a single setup, and a status view across every subsidiary.
Who it had to work for
Two groups meet the same path. The customer's NetSuite administrator, who does it a few times a year & every time meets it cold, this is where setups stalled & support was pulled in and the implementation specialists & consultants, who run it constantly & need it to stop costing them time.
Both gained, in different ways. Fewer first-run failures for the administrator; 30% less time on every one of 15 to 20 setups for the specialist.
06 - From Problem to Principle
What each finding committed me to
Five things the current flow revealed, and the rule each one set for the redesign. Every screen later in this case study is tagged with the principle it answers.
07 — Directions considered
No single pattern covered all five rules
This setup is interrupted, repeated per subsidiary, and often abandoned partway. I tested five guidance patterns against the five rules from the previous section. Four failed the same two and the one that passed most couldn't do the last one at all.
Product Guided Tour
An overlay walking the user through OBN registration, then Avalara provisioning.
Checklist
A persistent list of stages beside the setup, with state.
In App Resource Center
A help panel listing the setup articles.
Hotspot
Markers on fields inside the provisioning screen.
Video Tutorial
Explains the overall setup process through a guided video walkthrough
Tour, video and hotspots all assume one uninterrupted pass. This setup is never that, it stops at external dependencies, and the same admin returns to it 15 to 20 times. Only a persistent checklist could hold state between visits. But a checklist sits beside the work, so it could never put help at the field where a decision is made.
No single pattern satisfied all five rules, so the final design composes two: a rail for sequence and state, inline guidance for the moment of decision.
08 — The design
The screen that carries it
Each callout is numbered to the principle it answers, using the same numbers as section 06.
The first run
First Run
Opening Electronic Business goes straight to parent subsidiary setup. Nothing else is available yet.
Parent Subsidiary Steps
The workspace opens: Subsidiary Setup List, Mandate Activation, Sandbox, Integration.
From here on
The list is home. Every subsidiary, its state, and where to resume.
The sequence isn't explained, it's enforced. Until the parent exists there is nothing downstream to do, so there's nothing downstream to see.
The same path, after
The same path after the redesign: one entry, one role for the required steps and no return to navigation between stages.
Subsidiary Status View
Each subsidiary's setup state, visible without opening it
Continue resumes from the stage it stopped at
Sandbox readiness shown alongside setup status
Every stage named, so the remaining path is visible from here
The test this screen had to pass: an admin returning after two weeks can tell which subsidiaries are done, which are blocked, and where to pick up, without opening anything or asking anyone.
Guided Setup Rail
The stages of one subsidiary's setup, with current position and what's complete.
In-product Guidance
Setup help at the verification field where the decision is made, replacing documentation that sat outside the product and went unused.
Every element above exists for one of the five rules. Nothing in the final design arrived without a reason from the current-state work.
09 — Trade-offs and pushback
Three moments where the design wasn't mine alone to decide: one I proposed and had to argue for, one the team settled together, and one where I chose certainty over flexibility.
What I pushed for, and what it cost
01 One role for the path that's required
THE PROBLEM IT CLOSES
Finishing one setup meant switching between OBN Manager and Avalara Manager four times.
WHAT I PROPOSED
A single role covering the setup end to end, so one person could finish it without changing identity partway.
WHAT WE SETTLED
Engineering scoped it into the release: one universal role across the three mandatory steps. Mandate activation is optional, so it kept its own role and its own steps, a customer who never needs it never gets the permission, and a customer who does changes role once, knowingly, rather than four times by accident.
▲ WHAT IT GAINED
The required path runs under one role from start to finish. The four switches disappear from every setup that doesn't touch mandate activation.
▼ WHAT IT COST
Mandate activation still requires a role change, and the reason for the split isn't visible in the flow, it has to be explained rather than shown. The role change itself wasn't free: engineering had to scope and build it alongside the release.
02 Enforcing the order
THE PROBLEM IT CLOSES
A first-time user can't reach the workspace until the parent subsidiary is registered. The sequence isn't explained, it's enforced.
▲ WHAT IT GAINED
Nobody can start in the wrong place, because there is no wrong place to start. The dependency is handled structurally rather than with a warning.
▼ WHAT IT COST
An implementation consultant who has done this fifty times still walks the parent setup before reaching anything else. I removed a shortcut experienced users would have wanted.
WHY I TOOK THAT TRADE
First-run failure was the problem we were solving. The support requests came from people doing this for the first time, not from the people who could have used a shortcut.
03 Bringing documentation inside
THE PROBLEM IT CLOSES
No clarity on which steps must come before others or which are prerequisites.
WHAT I PROPOSED
Setup documentation already existed, but it sat outside the product and went largely unused. I proposed moving it inline, at the verification fields where the decisions are actually made, rather than continuing to point people at pages they weren't opening.
▲ WHAT IT GAINED
Help arrives at the moment of the decision instead of in a document nobody opened. It's the only part of the design that answers principle ⑤.
▼ WHAT IT COST
Engineering had to build it, in a release that already carried the role change. And the external documentation still exists, so the same guidance now lives in two places, the full version outside the product, and a shorter, diagrammed version inside it. Every future change has to happen in both, or they drift apart.
10 — What I'd do differently
I'd have shown the boundary instead of explaining it
Mandate activation is optional, so it kept its own role and its own steps. That was the right call, but the reason isn't visible anywhere in the flow: a user who hits the role change has to be told why, in documentation.
What I'd do instead: make the split legible on the screen. Something as simple as the status list distinguishing required steps from optional ones would have carried the reason without a paragraph.