Introhive

Introhive Self-serve User Management

Designing a 0-to-1 admin experience that eliminated $100K in annual support costs

 

Company
Introhive

Role
Lead Product Designer

Timeline
3 months

Stakeholders
Reported to Principal Designer and Product Manager; partnered with Customer Success Managers

Scope
Enterprise SaaS platform used by large organizations to manage relationship intelligence, user data, and account administration.

Project Goal
Design a self-serve admin suite from the ground up — giving enterprise administrators direct control over user management, permissions, delegation, and contact merging. Initiated to reduce operational load on the Customer Success team and eliminate a growing volume of manual support requests.

Impact
- Projected $100K in annual support cost savings
- 1,685 support cases per year eliminated through self-serve automation
- Delivered a complete 0-to-1 admin experience covering five core workflows
- Designed for enterprise scale with no retraining required for existing admins

Introhive is a relationship intelligence platform used by enterprise sales teams. When an admin needed to update a user record — merge duplicate accounts, reassign permissions, update contact details — there was no way to do it themselves. Every change required contacting their Customer Success Manager by email or phone and waiting for someone on Introhive's side to make the edit manually.

This created a bottleneck in three directions at once: customers were blocked from basic data hygiene tasks, CSMs were spending significant time on low-value manual updates, and Introhive's support org was absorbing costs that didn't need to exist. Over a single year, the team logged 1,685 support cases tied directly to contact update and merge requests alone — at an estimated $60 per case.

The ask: design a self-serve admin experience from the ground up so customers could manage their own users without ever needing to pick up the phone.

My role

I was the sole designer on this project, working closely with one Product Manager who owned the roadmap and stakeholder relationships. I was responsible for the end-to-end experience — from initial discovery and flow mapping through to final UI specs handed off to engineering. All design decisions, from information architecture to interaction patterns to component states, were mine.

Design Decisions

The merge flow was the highest-stakes surface to design. Merging two user accounts is irreversible — once a record is collapsed, the history, permissions, and relationship data from both accounts need to survive cleanly in one. The design challenge wasn't making it easy to do. It was making it impossible to do accidentally.
The core tension: admins needed to move quickly (this was a self-serve tool, not a complex wizard), but the consequences of a wrong selection were severe enough that the flow had to force a moment of deliberate review before anything was committed. I landed on a four-step modal structure — initiate, select source, select target, confirm with full profile preview — rather than collapsing it into a simpler two-step flow. The extra step exists specifically to surface the data that will survive the merge before the admin commits, not after.


I also designed explicit success and error states. A failed merge redirects to support with context already attached — the admin never ends up in a dead end wondering what happened.

The solution

The final deliverable was a complete admin settings suite built from scratch, covering five core areas:

User management — a searchable, filterable table of all users in the system with inline profile access, bulk actions, and key metrics surfaced at the top (total users, licensed seats, active users, delegates).

Permission groups — Administrators needed to create named permission groups, define granular feature access, and assign users either manually or through mail connector distribution lists. The assignment method — manual or automatic — is the first decision surfaced in the creation flow, because it determines everything that follows.

Each group has two tabs: permission settings and users. Permissions are presented as plain-language toggles rather than technical strings — every option explains what the user will actually be able to do, not just what the permission is called.

Manual assignment uses a filterable user table with a live selection count. Automatic assignment connects to a mail connector group, which populates the group dynamically.

Groups stay inactive until an enablement date is set. A persistent warning banner prompts admins to complete that final step rather than letting it get missed.

Default settings — a settings group system that lets admins define default preferences for large user segments and assign users automatically or manually.

Delegate management — a modal-based flow for assigning delegates to users directly from the user management page.

Self-serve merge — the headline feature: a four-step guided modal allowing admins to find, review, and merge duplicate user accounts without contacting support, with full profile preview before commit and explicit error handling throughout.

Outcome

The self-serve merge feature is projected to eliminate approximately $100,000 in annual support costs — based on 1,685 contact update and merge cases logged in the 12 months prior to launch, at an estimated $60 per case resolved.

That figure is a minimum. A single support case often contained bulk requests — in some instances, a spreadsheet of 100 or more contacts — meaning the true case volume absorbed by support was higher than what the reporting captured. The real deflection impact is larger than the number suggests.

$100K
Projected annual savings

1,685
Support cases/year eliminated

$60
Cost per case resolved

The 1,685 case figure is a minimum estimate — bulk requests and cross-classified cases mean actual volume was higher. Framing this honestly in your case study builds credibility rather than undermining it.

Reflection

If I were doing this again, I'd push earlier for a way to measure post-launch adoption, specifically what percentage of eligible admins used the self-serve merge within the first 90 days, and whether any edge cases surfaced that we hadn't designed for. The impact data we have is strong, but it's projected from pre-launch support volume rather than measured from post-launch usage. Pairing the cost savings number with actual adoption data would make the case study even more defensible.