Intro
As a company, Dropbox’s aim is to help its users “focus on the work that matters.” Yet for all its strides in fostering creative collaboration in the digital workspace, one place where it had been falling seriously short of this credo was in the realm of billing management. While much opportunity existed to grow this area into a world-class experience, a smaller set of three key issues stood in the way of unlocking the table-stakes user experience needed for Dropbox to start living out its creed.
Problems
1. Finding receipts is hard. (Billing emails don’t help.)
Though the email below appears to be a receipt, in reality it’s a tease. Dropbox email bodies didn’t include (nor did they lend themselves to including) the much more thorough information needed to actually expense receipts in most cases.
Without this expensable information handy in emails, many users were trained to ignore them. Untold numbers felt the need to instead manually hunt down the individual receipts via the admin console. Of these, thousands per year got lost and spent days on average waiting for resolution.
>4,000/y
CX tickets w ‘find_invoice’ tag
50hrs
avg time-to-resolution
2. Bill recipients are (often wrong and) set in stone.
Billing emails were often sent to the wrong person. Team creators would receive them by default, but they weren’t explicitly warned this would happen, nor were they (or their teammates) able to change it. If the creator left the team, billing emails could become inaccessible.
3. It’s hard getting bills to the right person
The people who needed the receipts were often non-users who couldn’t access a team’s billing history—at least not without the help of an intermediary. They were often an outside AP/Finance contact whose role would not justify additional license headcount, so this intermediary often had to manually download and send receipts to them.
Many non-users request receipts:
Send me also the invoices for the months January-October 2017 and January-February 2018. Define that any further invoice is automatically sent to [email protected]
Non-Team Admin
(via CX ticket escalation)
Defining Success
MVP
- Billing emails have expensable receipts
- Billing emails can be re-routed to any address
Out-of-scope: Integrations with third-party expensing software; Auto-generated shareable Dropbox invoice folders; Major updates to structures of user roles in teams
OKR
- 30% drop in CX tickets (‘find_invoice’ category)
Others metrics to watch: “Expensing is easy” Likert score in CSAT/CES survey; Time to resolution (TTR) and first-contact resolution (FCR) for ‘find_invoice’ CX tickets
Exploration
Before jumping into solutioning, it pays to do some homework up front. High-level groundwork—like mapping user journeys, and auditing potential touchpoints for the new functionality—paid dividends by illuminating design challenges needing further attention in later phases. (E.g., how would users know if they had been (un)assigned to receive billing emails?)
Other decisions could already be made with the collateral from this early phase. For instance: How could users wanting to re-route billing emails best be intially made aware of their ability do so, without needing to hunt for the functionality or ask Customer Support?
Mapping out the user journey offered insight into the above question. Within the journey map, the transactional emails themselves emerged as a highly contextually relevant option from which to link the functionality. (Freshly-annoyed recipients wanting to opt-out could easily spot a link to the functionality, while all others could easily look past it.) Moreover, the flow chart showed that these emails were universally surfaced to users across all variants of ongoing Growth experiments.
This was just one of many examples where doing a bit of homework upfront provided a springboard for later design work.
Solutioning
1. Finding receipts is hard easy. (Billing emails don’t help.)
So the previous example informed one design decision around transactional email: namely, the inclusion of language speaking to why the user received the email, and a link to change the recipient going forward.
But this was just one of the many email design decisions. Another one—in fact, the one most relevant to the MVP priority of the project—was how to make receipts easily accessible from billing emails.
Because PDF attachments were out-of-scope due to technical constraints (and because they often hit spam filters), a direct link was instead included. Next, the (now redundant) transaction details were removed from the email body in order to keep the email tone more amiable and focused on Dropbox’s value.
Lastly, the emails’ styling were updated to bring them in line with a major brand refresh the company had undergone not long prior.
BEFORE:
- Doesn’t contain expensable receipt
- “Teases” with unhelpful transaction details
- No way to unsubscribe or delegate
- Outdated branding
AFTER:
- Direct link to expensable receipt
- Body copy friendly and focused
- Context on receiving email; with opt-out
- Up-to-date branding
2. Bill recipients are (often wrong and) set in stone easily updated.
The other MVP priority of the project was to allow billing receipt emails to be re-routed to any address. For simplicity’s sake, this recipient’s role was conceptually decoupled from that of the “billing admin”, which was a role in the middle of a major potential revamp by another team.
Because this conceptual unbundling entailed breaking the role out onto its own line item in Settings, this begged the question of how to title it—i.e., what to call the role. Various role names were tested (“Billing contact”, “Bill recipient”, etc.); but ultimately, using a highly literal instruction (“Send receipts to:”) proved to be the clearest to users.
From there, the last piece was to design form validation patterns to reflect the potentially sensitive nature of sending receipts outside one’s team, and... voilà! Both MVP’s had been addressed.
2. It's hard easy getting bills to the right person.
So billing receipts could finally be sent outside the team. Hooray!
But not so fast... this introduced its own set of challenges. For one, how would different user types know about role changes affecting them? Email was the only touchpoint for outsiders, but DBX users were already concerned about email bloat (according to interviews with users and other designers.)
Luckily, consultations with product experts yielded at least one channel with high engagement for users: OS notifications. Thus, a hybrid approach was taken, with tray notifications for users and emails for non-users.
Another design challenge with introducing non-team members was how to build in remediation for when outsiders were wrongly assigned. They wouldn’t have access to the admin console, and for security reasons, we couldn’t give the name or email of the user who assigned them. So instead, we had to rely on an unsubscribe link from the email. This link would, in turn, land them on a standalone page confirming the status of their opt-out, along with any relevant details (especially handy in edge cases, such as if the team had disbanded.)
Results & Reflection
In a slightly humbling turn of events, much of the effort from this project needed to be shelved until H2 ‘19 due to a high-level company decision to re-architect a number of pieces of the eng stack upon which this project happened to depend. As such, there was limited opportunity to measure impact and success, but I can offer my own reflections.
On the small scale, retrospection offers a few decisions I may have made differently (e.g., potentially doing more upfront testing to validate the removal of transaction details from email bodies.) At the grand scale, however, I believe flexibility and equanimity in the face of shifting tides beyond one’s control are virtues that designers (and professionals more generally) need to embrace; so in that sense, there isn’t much I would’ve changed.
One notion that was validated by this project’s ultimate pause was that going the extra mile can often pay off in unforeseeable ways. Namely, when encountering the lack of email templates up-to-date with company brand guidelines, I faced a decision around whether to make the bare minimum updates to get my own emails out the door, or to parlay that design work into a set of templates that could be used broadly by anyone at Dropbox. To the chagrin of my schedule, I chose the latter, and reached out to the digital marketing team who was eventually able to help implement updates. Though this choice entailed an initial sacrifice, these updates turned out to be the first work from this project to see the light of day. And metric or not, shipping anything that simplifies other people’s lives lands in my book as a success.
