Key learnings: Butlers work at night, walking and carrying bins, often in low light and with no signal.
Project overview
Butler Plus provides valet-trash and property services to residential communities across 34 US states. Its day-to-day operations ran on disconnected apps, spreadsheets, email and manual checks.
The project team was brought in to rethink an underperforming product built by an external vendor. Early on it became clear the problem wasn't a few screens: it was the whole service. I led design from kickoff to release, reframing the brief from "fix the app" to "design the operating ecosystem".

What I owned
- DiscoveryLed stakeholder and user interviews, field observations and discovery workshops with the operations team.
- Service definitionFramed the problem statements and design goals, mapped the user journey and service blueprint, and defined the new app ecosystem.
- Product designPlanned the roadmap and designed the four MVP products end to end, including the AI flows.
- ValidationRan weekly validation loops with stakeholders and field users.
- Backlog managementManaged the backlog with the product owner and wrote the user stories.
- DeliveryPartnered with engineering on handoff and design QA, and helped the client plan the launch through small-group pilots.
Main project objectives
Process
Over 11 months, the project ran in two phases. Each phase followed the same four stages and opened with a 3-week discovery. Define and Design ran in short loops, validated every week with stakeholders and field users. Delivery was planned in two-week sprints.
AI as a design partner: how I set up the project in Claude
- Shared Claude ProjectSet up with my role as lead designer, plus industry context, scope, vision and goals.
- Growing knowledge baseTranscripts, interviews and client documents added as the project moved forward.
- Connected toolsConnectors gave the AI full visibility and let agents complete tasks for me.
- Custom skillsReusable skills like “From refinement to design” turned client sessions into requirements.
-
1
Discovery
Understand field workflows and the business operations behind them.
- Project kick-off
- Stakeholder interviews
- Business requirements
- Field observations & ride-alongs
- Market & competitive analysis
- Current-state system mapping
AI support- Research summarySummarizing research outputs and spotting early patterns.
- Competitor analysisPulling real competitor data from trustworthy, accessible sources.
-
2
Define
Turn findings into a shared view of problems and priorities.
- Product roadmap
- User personas
- Pain-point clustering
- User journey
- Service blueprint mapping
- Opportunity identification
- Backlog prioritization
AI support- SynthesisExtracting data from transcripts to build scenarios and use cases.
- Flagging gapsCapturing open project questions and keeping them visible.
- Backlog supportSupporting the creation of user stories.
-
3
Design
Shape the future ecosystem and its key experiences.
- Future-state journeys
- Ecosystem architecture
- Interactive prototypes
- Low to high-fidelity design
- Validation sessions
AI support- ExplorationGenerating variants with pros, cons and a recommendation.
- Rapid validation prototypesBuilding self-contained HTML prototypes.
- Interaction & UX detailsGetting insights and validating design patterns.
- CopywritingWriting quality content in the established tone of voice.
-
4
Delivery
Bring the design to production with the build team.
- Developer handoff
- Design QA
- Release support
AI support- AccessibilityGetting recommendations and validating solutions against WCAG.
- Feedback organizationOrganizing feedback on the designs for future iterations.
1Discovery – Explore the Business
To map the current state of the service, understand its problems at the root and spot opportunities to improve it, I had to look at it from every side: in the field at night, observing Butlers and asking questions; in workshops with the operations teams; and in interviews with the leadership at the top of the organization. A big part of the research happened in the three-week discovery that opened each phase, and it continued through every step of the project to validate ideas and dig deeper into specific features.
Key learnings: every role had its own tools and workarounds, and nobody had the full picture of a single service.
Key learnings: leadership’s view of the field was often distorted, so attention went to the wrong issues. Field evidence refocused priorities on the real causes.
Field observations: Observing the service up close
The business stakeholders’ view alone wasn’t enough. To understand the real service, I went into the field with the operations team who deliver it every night.







“We want to use the phone only when it really matters.”
What it meant for the design
- Guided, linear flowOne step at a time, no deep thinking required.
- Big, glove-friendly targetsLarge touch areas that work even with gloves on.
- Short device interactionsCapture what matters, then get back to work.
Interviews
One-on-one conversations with Butlers, Field Managers, Ops Managers, Customer Support and residents revealed what every role was missing.
- No reliable service evidenceComplaints turned into disputes.
- Managers were blindProblems surfaced only once they escalated.
- Support lacked contextEvery resolution was slowed down.
- The data existedBut it was scattered and unusable.

Tracing the roots of the problem
The client’s main request was simple: “We need to improve our service quality.” My research showed that every issue we uncovered fed into that one problem. Mapping them in this diagram helped me show the client that poor service quality wasn’t something to fix directly. It was the result of smaller root causes that had to be solved first.
- Field: weak training, heavy manual work and inconsistent data.
- Management: no central dashboard, no service control.
- Support: poor communication tools and no single source of truth.

2Define – Converge the research outputs
The research was converged into personas, key insights and an end-to-end map of the current service.
Defining the personas involved in the service

Mapping the current user journeys

3Design – Build a new system
One service-agnostic platform supporting every operational and management role, designed around real workflows and structured data.
Design goals
- 1Fix the data at the sourceRebuild how Butlers capture data in the field, for cleaner data and a simpler, guided experience on the job.
- 2Automate the back officeStreamline critical operational workflows, such as service review and customer support, and implement AI agents.
- 3Give managers controlRedesign the Management Portal and add essential tools to improve visibility and control, such as real-time service dashboards and an automated scheduling system.
- 4Give customers visibilityIntroduce two new platforms, a Client Portal and a Resident Page, giving customers more visibility and a direct voice to improve their experience.
Mobile Service App
Butler
FieldManager
Management Portal
CustomerSupport
OpsManager
FieldManager
Client Portal
Client
Resident Page
Resident
Ecosystem
The Mobile Service App
The quality of the whole system starts with how a Butler delivers the service and captures data, so this was the most critical piece.
“We want something easy to use, that doesn’t make us think too much.”
- The challengeButler data was unreliable: mandatory steps were skipped and photos were uploaded hours later, often from places with no signal.
- The solutionAn offline-first app that guides each Butler step by step and captures every check in real time.
Butlers used to upload data after the service, which made it unreliable: old or wrong photos were sometimes submitted. The bottleneck was that some community areas had no internet connection, so the system had to allow uploads after the service, once the Butler was back online. I convinced the client to require instant uploads and pushed the tech team to build an offline mode, so the app could capture data during the service and sync automatically once connected. Wrong photo uploads and Butler fraud dropped sharply.
Trade-off: more build effort and less freedom for users, but reliable data from every service.
Guided clock-in flow
Every service starts with a few required checks, but Butlers often skipped them, leaving the back office without the data to assess each community or judge service quality. I replaced the old open form with a guided, step-by-step flow: each check must be captured, or skipped with a valid reason, before the service can begin. This shift was one of the biggest drivers of better service data.
Automation with AI
Once Butlers were capturing clean, structured data, the focus moved to the back office, with one question: where can AI remove the most manual work? Two areas made the biggest impact: reviewing service data and managing requests from clients and residents.
AI service review process
Every night, 1,500 Butlers use the Mobile Service App to log their services, capturing 3,000–6,000 photos of on-site evidence, hazards and infractions and generating over 20,000 data points. This data was the company’s clearest window into real service quality, yet reviewing it was fully manual, slow and expensive: an offshore team checked every photo and record, more than 5,300 service IDs a week. Now a set of AI agents reviews the data and, based on the company’s business rules, scores each service, and those scores feed into the performance evaluation of Butlers and managers. Read my article about this case study ↗
✦ 3 AI agents working together
✦ 2 AI implementation stages


AI-powered ticketing system
Requests used to land in one shared Outlook inbox, where an offshore team sorted hundreds of emails and calls a day across dozens of labels. Now an AI agent turns every message into a tracked ticket, linked to the unit, the service and its photo proof.
- Emails arrive
- ✦ AIAI agent reads & classifies
- ✦ AITicket created automatically
- Tracked with reminders
- Resolved with evidence

After launch, users asked to edit email subjects and add or remove recipients in the portal’s built-in messaging tool. Before it went to the backlog, I pushed the team to dig into why. The AI agent links each conversation to its ticket by tracking subjects and recipients, so those edits would break the thread and push communication back to unstructured email, exactly what the system replaced. I convinced the product owner to hold the line, keeping every conversation centralized and visible to management.
Trade-off: less flexibility for users, but one reliable source of truth for every ticket.
Full control over every request. Faster decisions with proof at hand.
Consistent quality everywhere. A customer team always on top of things.
The Management Portal
The operational heart of the ecosystem: one web app where managers and support teams plan, monitor and resolve the service, replacing spreadsheets, email loops and static reports.
Fully automated scheduling
Every month, the schedule is generated automatically from community and service rules, so managers no longer have to build it by hand.
Live service tracking dashboard
Managers see the night's service as it happens: completed routes, missed units, open issues and performance by community, so they act before problems escalate.
The Client Portal
With operations under control, the system was opened to the people paying for the service. The Client Portal gives property managers a dedicated space to see the value of what they pay for, with clear evidence instead of back-and-forth emails.
Request & complaint ticket tracking
Clients get full visibility on every ticket opened by them or their residents, and can track its status in real time.
Proof of service
Photo-verified records of each service, so disputes are settled with evidence, not opinions.
The Resident Page
A simple page that gives residents what they need without calling anyone: when the service happens, how it works and how to report a problem.
Service schedule
A weekly calendar shows residents which services happen in their community and when, accessible from the flyer QR code.
Easy issue reporting
A short structured form replaces free-text emails, so every report arrives complete and turns directly into a ticket.
Service guidelines
Links to the community’s service rules and documentation, so residents know what to expect before they need to ask.
The client wanted the MVP to show residents every service detail and send push notifications during the service. I challenged it. Notifications could only follow the schedule, since offline mode meant no real-time location, so residents might hear “service started” when no Butler was there. With operations not yet consistent, that risked hurting trust. We removed notifications from the MVP.
Trade-off: less real-time awareness for residents, but no promises the service couldn’t keep.
4Delivery – Launch the product
The rollout started with small-group pilots to refine the experience in the field, then expanded to the full workforce.
A system built for one service, scaled to five
It was launched with valet trash. Because the system was designed to be service-agnostic, the team added four new service lines by configuring new business rules, without redesigning the product.
First serviceValet trash
Doorstep trash pickup on scheduled nights.
Pressure washing
Cleaning of sidewalks, breezeways and common areas.
Pest control
Scheduled treatments for buildings and units.
Porter service
Litter pickup and upkeep of shared spaces.
Bulk hauling
Removal of large items and move-out waste.
“Each new service line has cost about 10% of what it took to build the first, and that gap keeps growing.”
Lessons learned
Understand the problem before choosing the AI solution
Excited about AI, the client arrived with ambitious ideas based on little analysis. I challenged them and proposed mapping every bottleneck across the system first, to see where AI would have the highest impact, weighing implementation time so they could see results quickly. The client was grateful for being made to look at the whole picture before rushing into decisions.
Especially with AI, start from the problem, not the solution.
Listen to the people who deliver the service
The original plan was to run discovery with business stakeholders only; they said they had already gathered feedback from the field, so talking to the Butlers wasn’t needed. I pushed to include the Butlers, sensing the field would reveal what business meetings couldn’t. The field observations cleared up many open questions and revealed the values and limits to design around. User satisfaction rose from the first releases, with Butlers saying they finally had everything they needed.
Good design comes from balancing business requirements with real user needs.
Design for what the client needs, not only what they ask for
The ticketing system proposal completely changed how the team worked, to cut manual effort in the long run. Most of the client team leaned toward a hybrid between the old process and full automation. The design team made the case for the bigger change, showed the downsides of the hybrid and answered every technical question until the design was solid. The PO approved it for production, and after a short adaptation period the team was grateful for the push toward the fully streamlined solution.
Design for what the client needs, not just what they ask for, while knowing when an exception makes sense.
