Increasing satisfaction in iRobot Select's Auto-Delivery

With iRobot Select's Auto-delivery, subscribers receive cleaning accessories for their robots automatically on a recurring basis. I joined the Select team to improve the auto-delivery experience for subscribers and the Select program, increasing subscriber satisfaction by 10% and reducing support call volumes by 40%.

Current iRobot Select member portal home screen, displayed on a mobile phone and laptop

Recognizing there was a problem with Auto-Delivery

We set up ongoing surveys to gauge our customers' membership experience, and we discovered a problem people were having with Select's accessory auto-delivery:

  1. Parts broke or wore out before a new part shipped.
  2. People stopped using their Roombas until the new accessories arrived.
  3. New accessories don't arrive, so the Roombas remain unused!

This was happening because the robot's cleaning hours trigger the auto-delivery system. If the robot isn't being used, auto-delivery doesn't kick in. We could not differentiate between people who chose to pause their robot and people forced to pause a robot in need of replacement accessories.

This was a big issue for our customers who are now paying for a robot that can't clean and a service that's not delivering. It wasn't good for us either, because we were running the risk of shrinking growth and revenue if customers cancelled their memberships.

We needed to work with what we had

The iRobot Select team was a small pilot program with limited resources when I joined. Changes to the iRobot mobile app, shipping, and actual hardware were off the table when it came to addressing this customer problem.

That left the Select portal, a web-app for managing one’s Select subscription. Within the portal, I hypothesized the accessory health dashboard was a good place to focus early design iterations: it features prominently in the portal, directly relates to the problem, and is well trafficked per heatmap and site traffic data I reviewed.

iRobot Select portal home screen, displayed on a mobile phone before work on this project started.

Balancing subscriber and business goals across iterations

Subscribers needed their robots operational, which required working parts. To that end, I wanted to the health dashboard to display an obvious way for subscribers to get those new operational  parts.

  1. Large CTA on health dashboard for quick discoverability and access.
  2. Subscribers can request 1 or multiple parts at once for convenient access to multiple replacement and spare parts.
  3. Shipping savings to deliver multiple parts in a single order
first Iteration of user flow to request new accessories

Figure: Early iteration of accessory request experience intended to help subscribers efficiently get the parts they needed.

My PM partner had concerns about this proposal. He felt there wasn't enough friction, that too many subscribers would order accessories on a whim rather than out of need. Since accessories are included in the subscription fee, he was sensitive about unnecessary requests eating too much into Select's revenue.
‍
I made some key adjustments to accommodate his concerns:

  1. Embed request CTAs in accordion pattern.
  2. Separate flows for each accessory, so subscribers must request accessories one at a time.
Iteration of user flow to request new accessories that reflects feedback from my product manager

Figure: Updated proposal to accommodate business concerns of early design efforts. Added a bit more friction to reduce casual requests.

Usability testing revealed that people readily identified where to go and what to do to order specific new accessories. Furthermore, heatmap data indicated that subscribers were already tapping and clicking on the parts in the accessory dashboard, expecting it to be more interactive than it currently was.

To further mitigate potential fraud and excessive costs, my PM and I decided to limit requests to 3 every 4 months before routing subscribers to a customer care contact page for help.

Avoiding requests in the first place with personalized auto-delivery

Until hardware can detect broken parts automatically, people will need to request those manually. But what about those that wear out early? How can we reduce or remove the work of requesting those accessories for our customers?

By incorporating a multiple-choice question about the nature of the request, we could collect data to identify trends and adjust the auto-delivery predictions for individuals and/or the whole program as necessary. Personalizing auto-delivery might lead to subscribers requesting new parts less because auto-delivery timing is more attuned to their cleaning experience.

When testing a prototype of the experience, participants appreciated the opportunity to provide this feedback so that it could be used to tailor the Select experience.

Iterations of Select portal highlighting the multiple choice question presented to customers requesting a new part. We ask why someone needs a new part, and their options are: It wore out already; it broke; I'd like a spare; and an "Other" option to write in a reason.

Figure: Request experience gives users opportunity to specify why they need a new part. This may help the Select team create a personalized delivery experience per subscriber, or make global tweaks to auto-delivery timing.

Tracking spare part installations to save money and reduce waste

Roombas cannot detect when a brand new part is installed, so knowing when one is presents a real challenge. For regular auto-delivery parts, Select assumes the part is installed upon delivery. For spare parts, we need to rely on subscribers telling us, So I designed a way for subscribers to disclose a date of installation. Disclosure is beneficial for several reasons:

  1. Saves iRobot money (fewer parts shipped too early)
  2. Cuts down on waste (fewer parts replaced before they need to)
  3. Reduces clutter for subscribers
  4. Preserves our “intelligent auto-delivery” timing
Select portal user flow for people to disclose when they actually installed a cleaning accessory.

Figure: Mechanism to support subscribers disclosing when they installed accessories.

Improving the mobile app to keep Roombas running

iRobot Home mobile app displaying "ready to vacuum" status, indicating a roomba can be commanded to clean.iRobot Home mobile app displaying "Clean Base: dust bag full" status, suggesting a roomba needs a new bag before it can clean again,iRobot Home mobile app displaying "ready to vacuum" status with an error message indicating a roomba can be commanded to clean, but the bag is full.
iRobot Home app home screen, various robot statuses.
(Left) Status when everything is working normally; (middle) former status when dust bag is full; (right) my updated status when robot’s dust bag is full

When a dirt disposal bag became full, the mobile app copy implied the roomba wouldn’t work until a new bag was installed (middle image). This frustrated many subscribers who hadn’t received their next bag yet, and some even stop using their Roombas while waiting for a new bag.

However, Roombas CAN still work if a bag is full or missing! I drafted new status copy (right image) and worked with the mobile app team to prioritize its development.

By communicating both the robot’s current readiness in the midst of a full bag, this should help Select subscribers keep using their roombas while waiting for a new bag and maybe even save Select money via reduced the bag requests.

Three views of the iRobot Home mobile app Product page displaying different robot statuses. Left to right: Existing status when no errors present - "Ready to Vacuum"; previous status when dust bag full - "Clean Base: Dust bag full. The clean Base bag is full. Insert a new bag."; My updated status when dust bag full - "Ready to Vacuum. The clean Base bag is full. Insert a new bag".

Figure: iRobot Home mobile app Product page (blurred for emphasis) displaying robot statuses.
(Left to right): Existing copy when no errors present; former copy when dust bag full (original copy); new copy when dust bag full.

Putting it all together

Throughout the project I worked closely with my UI design and development partners, checking in regularly to make sure we were aligned and the designs were feasible and buildable in time and on budget. The net result of fostering those relationship was a successful handoff of my design work for implementation

Requesting new accessories

Implemented user flow for requesting a new accessory in the Select member portal.

Implemented user flow for requesting a new accessory in the Select member portal.

Installing spares

Implemented user flow in the Select member portal for editing when the current cleaning accessory was installed.

Implemented user flow in the Select member portal for editing when the current cleaning accessory was installed.

Mitigating fraud

If Select members exceed their request limit, they're presented a contact menu for Customer Care. This is intended to prevent fraudulent behavior.

If Select members exceed their request limit, they're presented a contact menu for Customer Care. This is intended to prevent fraudulent behavior.

The results: satisfaction up 10% and replacement calls down 40%

After Send Accessories Now launched, customer satisfaction with Select’s Auto-Delivery service rose steadily. After 6 months, satisfaction had increased 10% and remained at that elevated level.

Additionally, calls to the Select support team requesting new parts decreased significantly and rapidly, by approximately 40%! This decrease also remained after launch, freeing up the support team to field other pressing subscriber issues.

View other projects

[Redacted design for new robot/app UX]