Turning org config and user management into something teams chose how to run.

The problem

Getting an organization onto Blume was a fractured, manual process. A single customer support agent could onboard about 100 orgs per week, and bringing a large customer's network on could stretch into months. Every org arrived with its own internal structure and its own ideas about who should be allowed to do what, and the process flattened all of that.

Discovery and definition

I ran this as a classic double diamond: diverge on how organizations actually structure themselves, converge on an architecture that could hold all of them. The answer was three levels (org, division, individual) with an ecosystem of permissions to match, so a company could configure how it's organized before anyone books a thing, without losing its internal architecture on the way in.

The design

Org admins onboard their own users and hand out specific permissions. The part people loved most was self-service dashboard setup: you build your primary dashboard by choosing widgets from a menu instead of inheriting a fixed layout (the widget-grouping pattern carried over from the control-tower work, and those widgets turned out to be the most-selected). Behind that friendly surface sat the sequence work, mapping onboarding end to end (sign-up, workspace setup, org structure, invitations) so each screen only asked for what the last one had earned.

Aligning with development

Once the design was proven, I ran a workshop with the dev teams to align the information architecture with the data model, so the org/division/individual structure the design promised was the structure the system actually stored.

The outcome

Once live, about 5,000 new orgs onboarded in under a week — against the old baseline of 100 orgs per support agent per week, a process that used to take months. It shipped, it stuck, and it turned the dullest corner of enterprise software into something teams actually chose how to run.