Juice Ops: what if operations lived in one place?
The customer-operations platform my team at The Juice runs on every day, built by a teacher.
The mess
Like a lot of growing companies, our customer operations lived everywhere and nowhere: a CRM, a help desk, analytics dashboards, spreadsheets, and long email threads. Each tool was fine. Together they disagreed constantly. Answering a simple question like "how is this district actually doing?" meant opening five tabs and doing arithmetic you'd redo next week.
What I built
One console where the whole customer story lives. Accounts flow in from the CRM automatically. Onboarding runs on a visible pipeline with stages everyone shares. Support tickets, usage analytics, and rostering data attach themselves to the right account. Districts get their own partner portal with a setup wizard and health reports. Scheduled jobs keep everything fresh so nobody re-types anything, ever.
It also teaches itself: the platform ships with an in-app guide, role by role, and a set of playbooks that walk teammates through real scenarios. That part is the teacher in me. Software that requires a training meeting has already failed one.
Decisions I'd defend
- Orchestrate, don't replace. The CRM stayed the CRM. The help desk stayed the help desk. Juice Ops sits on top and reconciles, which meant nobody had to migrate anything or change how they work on day one.
- Fail closed on permissions. Every role (admin, customer success, engineer, partner) sees exactly what it should and nothing else, enforced at the database layer, not in the interface. When I got it wrong early on, real-user testing caught it, and the fix went in the same day.
- "Healthy" is configurable. Account health isn't a magic score. It's a set of plain-language dials my team can calibrate, because they know what healthy looks like better than any formula I could freeze in place.
- A demo district lives inside the product. A fully seeded sandbox account, filtered out of every real view, means we can test, train, and demo without touching customer data. Fake data is a feature.
- The guide updates with the feature. House rule: if something user-facing changes, the in-app guide changes in the same sitting. Documentation that lags is documentation that lies.
What it taught me
Building this felt less like engineering and more like curriculum design: figure out what people actually need to know, sequence it, remove everything that distracts from it, and check for understanding constantly. The stack was new to me. The method wasn't.