Neighborly
Project OPUS: Platform Transformation
Neighborly: One Platform for 20+ Franchise Brands
UX strategy, information architecture, design system, and native app for the parent company of Molly Maid, Mosquito Joe, Mr. Rooter, Mr. Electric, and more.
The problem
Each brand Neighborly acquired came with its own website, booking system, and franchise operating model.
Customers got a different experience every time, and nobody had ever mapped how a single customer journey
crosses the end customer, the franchise owner’s point-of-service platform, and Neighborly’s central
Call-a-Neighbor system.
What I did
I framed the work around three customer jobs (Repair, Maintain, Enhance), aligned 20+ brand stakeholders on
one journey model, led the design system that let every brand keep its identity on shared components, and
carried the same framework into the native app.
Metric
Brands migrated onto one platform
20+
Conflicting requirements entering design review
−60%
Time to launch a brand, first wave vs. last wave
~65% faster
Share of each new brand’s experience built from existing components
75–85%
Lead form booking completion rate
+30%
Mismatched leads sent to franchise owners
-40%
Chapter 01. -
Strategy
Untangling the Hairball: One Customer Journey Across 20+ Brands
My role
Led UX strategy, research framing, and cross-brand alignment
Partners
Brand presidents, PMOs, Engineering, Marketing, SEO, CRO
Timeline
Discovery and workshops took 2-3 Weeks on a rolling per-brand cadence
Result
Sign-off on one shared journey model; 60% fewer conflicting requirements in OPUS design reviews
The problem
Every brand defined “the customer journey” through its own tools. A single booking touches three
organizational lenses at once (the customer, the franchise owner’s point-of-service platform, and
Neighborly’s Call-a-Neighbor platform), and none had ever been mapped as one system.
Decision 1: Start from jobs, not screens
I framed the work around three jobs a customer is trying to get done: Repair, Maintain, Enhance.
Each demands a different tone and level of support from the brand. This became our shared vocabulary.
When a brand president asked why the booking flow didn’t work like theirs, the answer was usually
“that’s a different job.”
I built personas on Neighborly’s real customer segmentation rather than invented archetypes.
Two mental models became a lens for every flow: Diane (“show me options”) and Elizabeth
(“decide for me and I’ll review”).
Decision 2: Map the system, not just the customer
The core deliverable was a six-stage journey map (Needs & Planning → Research & Compare →
Books Service → Pre-Service → During Service → Post-Service). The fourth row, Behind the Scenes,
tied every customer activity to the platform doing the work. I also defined the trigger for each
stage change (for example, “franchise owner sends estimate” moves a customer from Research to Book),
so engineering could use the map directly instead of treating it as a workshop artifact.
Decision 3: Group brands by job, not by brand
Rather than negotiating with 20+ brands one at a time, I ran three working sessions, one per job category
(Repair, Maintain, Enhance), with all the brands in each category in the room together. Each session used the
same structure: Stage → Goal → Activity → Touchpoint → Platform. Because input landed in one format, we could
compare brands side by side and stop debating whose booking process was “right.”
- Working sessions held: 3 sessions across 20+ brands (Repair, Maintain, Enhance Categories)
- Brand presidents signed off on the shared model, with a rolling migration schedule of 15 waves, one every 3 weeks
- Conflicting requirements entering OPUS design reviews fell by 60%
A catch that mattered
While mapping, I noticed that one booking (a cleaning) triggers parallel paths through the central
platform and two franchise brands’ field operations, each with its own scheduling and lead-routing logic.
Flagging it early meant the prototype and build accounted for multi-brand routing from the start,
instead of surfacing in QA.
Results
Metric
Shared journey model signed off by brand presidents
All
Requirement-clarification rounds per brand before design started
~4 → ~1
Brands whose stakeholders adopted the jobs vocabulary in their own planning
13 of 20
Chapter 02. -
Platform
Project OPUS: A Design System That Let 20+ Brands Keep Their Identity
My role
UX Lead on OPUS; led design execution, the design system, and the blended design team
Team
10 people across in-house design, research, accessibility, and an offshore agency
Platform
CrownPeak CMS, Tailwind CSS, Flowbite (heavily customized), Figma
Result
20+ brand sites on one token model and component library, with a signoff gate that made “done” mean the same thing everywhere
The problem
Chapter 1 defined what the experience needed to be. This chapter covers the system that let it get designed,
reviewed, and shipped brand after brand without starting from zero each time.
Decision 1: Enforce structure, not appearance
Every brand runs the same token structure (Primary, Secondary, Accent 1, Accent 2), but the
values are brand-specific. A brand president sees their brand; engineering builds against one model.
I chose Tailwind and Flowbite as a starting point rather than an off-the-shelf answer, because the
foundation had to flex across 20+ identities.
Decision 2: Solve navigation first
Navigation had to scale across every brand’s service structure without becoming a bloated mega-menu or
an oversimplified one. I defined the principles on Mr. Electric first, and every later brand’s navigation had
to pass the same test: mobile-first, an easy path to requesting service, simple and logical structure, clean
use of white space, and consistency with room for brand personality.
Decision 3: Build once, reuse everywhere
Standard components (heroes, service grids, offer carousels, testimonial blocks, forms, location capture)
were built once against the token system. New brands got most of their experience “for free,” which made
the migration schedule realistic.
Decision 4: Turn gaps into permanent additions
Not every brand fit the library. We called these gaps deltas. Each one was designed,
reviewed, and folded back into the shared system instead of living as a one-off exception.
Decision 5: Make “done” mean the same thing everywhere
Every sprint followed the same cadence: design, internal review across the blended team, then a
formal signoff gate with product and brand stakeholders before anything went to engineering in CrownPeak.
With 20+ stakeholders and a mixed internal and vendor team, informal review would have meant every brand
renegotiating quality on its own terms.
Proof at scale
Mr. Electric (emergency electrical work) and ShelfGenie (considered home-storage consultations) don’t
read like the same product: different color, tone, and service model. Both are assembled from the same
components, tokens, and navigation principles.
Results
Metric
Brand sites on one platform
20+
Design-to-signoff time per brand, wave 1 → wave 6 *
~10 weeks → ~3 weeks
Components reused across brands
~80%
Design review rounds per brand before signoff
~4 → ~2
Accessibility issues found at pre-launch audit
−85% from wave 1 to wave 6
* Wave 1 was the expensive one, on purpose. The first migration took about 10 weeks because
it was where we worked out the process by trial and error. Every wave after that fed what we
learned back into the components, the deltas, and the signoff process, and by wave 6 the
same work took about 3 weeks.
Looking ahead
I also scoped a longer-term scenario in which AI and smart-home data shift Neighborly from
reactive booking to proactive service (a leak sensor triggering a repair booking, for example).
I was explicit about what was in and out of scope for the near-term demo, so the exploration
informed the roadmap without derailing current sprints.