02 — About
Context
NetSuite is where sales teams keep the customer record, but Outlook is where they actually talk to customers. The Outlook Connector is an add-in that lets reps log emails, attachments and contacts to the right NetSuite record without leaving their inbox. This was its first release for most teams.
The Problem
Logging an email into NetSuite was manual copy-paste work, one message at a time. Every reply in a thread started the job again, and attachments and the other contacts on the thread were easy to miss. In a busy week it simply didn't happen, so NetSuite was missing the conversations it was supposed to hold.
Role
User Experience Designer
Domain
CRM & email integration
Team
1 UX Designer · 1 UX Researcher · 1 Product Manager · 6 Engineers
Timeline
4 months (March – August 2026)
Status
Shipped (1st Release)
Impact
~87%
less time per manual sync
~96%
less time per thread manual sync
03 - Current Flow
How logging actually worked
Before the connector, getting one email into NetSuite was a manual job across two applications. This is the path a rep followed for every message, and again for every reply.
Every step happened by hand, in two applications, and nothing confirmed that it had worked. Scrolls sideways on phone at readable size.
7
steps to log one email
x7-8
again for every reply in the thread
0
ways to confirm it had worked
04 - Evidence
How I knew this
I've named each source and who ran it, because not all of it was mine.
Intervies Insights
Sales reps, managers and CRM admins. Run by our UX researcher; I built the framing from her findings.
Competitive review
CloudExtend, Workiro and SuperSync, reviewed together with the researcher.
The interviews were our researcher's; the competitive review we did together.
05 - Framing
What I designed for, and what I didn't
Three groups gain from a logged email, but only one of them does the logging.
Primary User
Sales reps — AEs, BDRs and SDRs. They touch every customer email, and theirs was the workaround that was failing.
Secondary User
Sales managers — a pipeline they can trust.
CRM admins — logs and retries they can act on.
Constraints I coundn't change
The Outlook panel is roughly a phone's width inside a desktop application.
There was a limit on how much automation the system could run.
Several ideas needed backend changes that were not in scope.
Redwood was new, and I was learning it while designing in it.
In this Phase, i worked on
Manual Sync, Redesigned
Thread sync
Rule sync
Activity log
Sync List
Event Sync
Email Templates
06 - From Problem to Principle
What the design had to do
Three things the research showed, and the requirement each one set. Every screen later in this case study is tagged with the requirement it answers.
07 — Decisions
Two decisions that shaped this
One came out of the flow map, the other out of a constraint I couldn't change.
01 - Two separate automation paths, not one auto-sync setting
WHAT I CONSIDERED
One combined "auto sync" setting covering both the conversation in front of you and standing rules, or two separate paths: thread sync for a conversation that already exists, rule sync for conditions that apply to mail which hasn't arrived yet.
WHY
One combined "auto sync" setting covering both the conversation in front of you and standing rules, or two separate paths: thread sync for a conversation that already exists, rule sync for conditions that apply to mail which hasn't arrived yet.
▲ WHAT IT GAINED
140
thread sync a day
120
rule sync a day
Both carry real volume, which is what the flow map predicted when I argued they should not be one setting.
▼ WHAT IT COST
Two paths means a rep has to understand the difference before choosing. That is more to learn than one switch. I took it, because the alternative pushes the confusion into the form, where it is harder to recover from.
02 - Manual sync stays the default tab
WHAT I CONSIDERED
Leading with automation, so thread and rule sync are the first thing a rep sees, or keeping manual as the default and placing automation one tab across.
WHY
Manual sync had already shipped internally, so it was the path people knew and the one we were confident in. More importantly, there was a hard limit on how much automation the system could run. Defaulting every user into automation would have sent them down a path the backend could not support at release scale.
▼ WHAT IT COST
The better experience is the one you have to go looking for. A rep who never opens the Auto tab keeps logging one message at a time, which is the behaviour this project set out to change. I accepted that for the first release, because a default that fails under load costs more trust than a default that is only slower.
08 — The design
Four jobs inside one panel
Each callout is numbered to the requirement it answers, using the same numbers as section 06. Unnumbered callouts support the screen without answering a requirement on their own.
Manual Sync
Matched records, attachments and the option to create a new record sit in one view, so logging is a single pass rather than a hunt through NetSuite.
The rep chooses exactly what syncs: which record, which attachments, which contacts before anything is sent.
▼ TRADE-0FF
At panel width, showing matches, attachments and create-new together means each list is short. A rep with many possible matching records has to scroll or search. I took that, because the alternative was splitting one task across two views.
Thread Sync
One choice applies to the conversation and every reply that follows it.
The record is picked once. Replies attach to it without the rep returning to the panel.
▼ TRADE-0FF
Thread sync is all-or-nothing. A rep who wants most of a thread logged but not one particular message can't express that here. I accepted it, because a per-message exception list inside a panel would have cost more than it saved.
Rule Sync
A rule logs matching mail that hasn't arrived yet, so the thread doesn't need to exist first.
1
Two steps: who the rule applies to, then which record type and records it writes to.
1
The rule stays visible and editable afterwards, rather than disappearing once set.
▼ TRADE-0FF
Two steps instead of one screen is more work to set up. Rules are set rarely and a wrong one quietly mislogs mail for weeks, so I chose the slower path that is harder to get wrong.
Activity Log
Every sync carries a status: successful, failed, partial or pending.
1
Retry is in the item's own menu, inside Outlook. The rep never opens NetSuite to fix a failure.
1
The full history and bulk actions live on a separate full page, linked from here.
▼ TRADE-0FF
At panel width only a few items and a truncated subject line fit, so the panel answers "did my last few syncs work?" and not "what happened last week?" That second question is what the full page is for.
Sync List
Every sync carries a status: successful, failed, partial or pending.
1
Retry is in the item's own menu, inside Outlook. The rep never opens NetSuite to fix a failure.
1
The full history and bulk actions live on a separate full page, linked from here.
The panel holds quick actions: sync, check status, retry. Everything that needs room: full history, filters, bulk retry across many records moved to a full page. A table with eight columns cannot work at the width of a phone.
Designed, pending release
AI Insight surfacing, note creation and thread summarisation. Designed in this phase, currently moving through Oracle's release process.
09 — Trade-offs and pushback
What this design gave up
What I accepted in exchange for shipping the first release.
01 - What the backend couldn't carry
THE DECISION
There was a limit on how much automation the system could run, so automation couldn't be the path every rep landed on. Manual sync stayed the default.
▼ WHAT IT COST
The rep who never opens the Auto tab keeps doing the work by hand. That is the cost I knowingly shipped, and the first thing the next phase should address.
02 - What the panel width cost
THE DECISION
The panel is roughly a phone's width, so it holds only what a rep needs mid-email: sync, check status, retry. The full sync history, filters and bulk retry moved to a separate full page.
▼ WHAT IT COST
A rep who wants last week's syncs, or to retry several failures at once, has to leave the panel. The panel can tell you whether your last few syncs worked. It can't tell you everything that happened.
10 — What I'd do differently
Each comes from this project rather than from general lessons about design.
I'd bring engineering constraints in earlier
Several of my early ideas needed backend changes that weren't in scope for this release, and I found that out after designing them rather than before. Each one meant reworking a flow I'd already taken to review.
What I'd do instead: bring an engineer into the first flow-map review, so a backend dependency shows up as a constraint at the start instead of as rework at the end.
I'd test with people who don't already know the product
Everyone who tested this was already working on it, so none of them could tell me whether a rep seeing the panel for the first time would find the automation at all. That was the thing I most needed to know.
What I'd do instead: run five sessions with reps new to the connector before shipping.
What's Next
The next phase moves to mobile, and changes how we start: gathering pain points from customers before designing, rather than designing and validating afterwards.