Blog Home

Lessons Learned from 4 Months of Customer Onboarding

Packet has been onboarding new customers since June, giving us about 4 months worth of data & insights into how we can improve the onboarding experience for our customers.  Even with a focus on customer experience, it's hard to get things right the first time (or second!).  

I'd venture to say that our first two onboarding attempts were just "okay" - but they certainly weren't great. However, we're big fans of improving our experience with data, piping most events through Segment, religiously viewing user experiences in FullStory and basically just engaging with customers whenever we can (via live chat, phone, in person, meetups or via   

If you need a few million ($) reasons to actually use tools like A/B testing and screen recordings, just read this blog from 37signals.

Zac's Latest User Session

Our Case for Investing in a New Onboarding Flow
In early August we decided that we had enough feedback from our first few months of onboarding customers that we were ready to make some fundamental changes. It's worth asking "what's so complicated about creating an account"?  I mean, a Packet account is free, and we only ask for 4 fields, right?!  Before I get into what we did and why, it might be useful to have a bit of context on our process and hard requirements:

  1. Our first priority is to make a legitimate user's signup experience as quick and painless as possible.
  2. We want to verify that we can communicate with a customer reliably, e.g. via email.
  3. We watch out carefully for user fraud, which we consider different from credit risk.  Bad users do bad things with powerful, on-demand bare metal servers (especially with 20Gbit network interfaces!)
  4. We also want to introduce customers to certain necessary details for using the Packet platform, primarily joining an existing Project and creating / uploading an SSH public key.

We knew that we could improve on #4.  Our users were telling us this, as were our tools.  For #2, we felt that getting stronger contact details from a user and simultaneously encouraging use of 2-factor authentication, could have a long term benefit for our customers.  

#3 one can only learn through trial-by-fire, and we had some good tricks that we wanted to implement (sorry, not going to share those here!).  

And finally, the most critical area of improvement was moving some parts of the onboarding process into the signup flow itself, versus trying to force that through the portal experience.  We were sure that improving on this last goal could help us "unconfuse" customers, and allow us to keep our portal experience focused on the business of high performance infrastructure - not about more setup muck.  

Take it Slow, Man.

Frankly, when Jacob, our head of revenue and all around web lead, and Felix, our chief UX designer, showed me revision number 10 of our new signup flow, I was a bit annoyed.  Was it really worth spending so much time on this?  Shouldn't we be using our precious time and resources on our new elastic block storage service or benchmarking our NVMe drives with a new NoSQL database?  Would improving upon our goals for onboarding come back to us sufficiently?  As the CEO of a lean, fast-moving startup I'm constantly asking myself these kinds of ROI-calculation questions - and it's made all the more difficult by serving highly technical users who stare at console screens more than they do Pinterest!

Happily for Jacob and Felix, I knew that the signup process is the first real interaction any customer has with our company.  If we didn't make the process better, we were cheating ourselves out of a great first date with new customers.  Since we could see both customers and our Ops team hitting the same walls over and over again, it was worth committing the cycles to make it better.

So, I stored up my patience, and we went through about a dozen more mockups.  We shared the refined process with our product team and then, after incorporating feedback (and ignoring some as well), we moved to internal user testing in our lab -- basically real forms, fake data.  A few more rounds and the team felt happy with with the result.

Packet User Onboarding

The Result
In the end, what did we do? We ditched what looked like a simple one-form signup (but actually had a lot more steps hidden away) and implemented what we feel is a longer, but clearer and more transparent 4-step process.  

By showing all the steps that were needed to really do anything useful with a Packet account, our hope and expectation is that there will be less confusion after signup - leading to a smoother onboarding experience.  

We also:

  • Removed some fields up front that we weren't planning to use;
  • Made it a requirement to validate your mobile phone via SMS short code;
  • Added an optional step to upload an SSH public key;
  • Added an optional step for entering payment details - a key first step in actually deploying any servers;
  • Polished some pixels, and added better validation for passwords and other fields.

The response?  So far, we've received some positive data points and personal feedback on the new process is good.  

More Room to Grow

I'm writing this blog with one tab open in FullStory, so it's easy to see that there is room to improve our signup flow even further.  We will soon be adding PayPal payments, for instance, allowing those without a credit card or (who don't want to share one) a quick, easy and trusted way to confirm billing details.  

We are on the fence as to whether to make providing a payment method a required part of the onboarding process...frankly, we're not sure yet!  But you can bet we'll be listening hard and watching the data so that we can continue to optimize.

Photograph of two men having a conversion outside by a table of servers
Let's talk

We’re excited to hear what you’re working on.

Ask a question