Is the "shopping-cart" paradigm suitable for buying add-ons in an SaaS?

Question

We are building an SaaS app where our users will have the opportunity to purchase add-ons such as custom domains, plan upgrades, templates and various other bits and pieces.

We are considering a flow like this:

^{download bmml source – Wireframes created with Balsamiq Mockups}

^{download bmml source}

I have looked at wordpress.com and for cases where they require the user to configure the add-on (such as buying custom domains), the shopping cart is bypassed and after filling in the information, the order is checked out immediately. In fact, the user never enters the store at all.

However, I feel that it's more consistent to redirect the user so that all purchases happen through the store. In addition, there are these benefits:

• Customers have the ability to combine multiple items into 1 transaction (which results in a lower processing fee (flat fee + percentage) for us.
• Customers will not have multiple transactions on their card during a shopping session.

One disadvantage is that customers can get distracted after adding the item to the cart by doing more shopping and might abandon the cart altogether.

So, the question: Is consistently sticking to the shopping cart paradigm suitable for buying add-ons in a SaaS app? If possible, I would love to seem some research/studies for cart abandonment in this scenario.

Answer 1

I've actually done some research/work on this recently. Your decision depends on how you want users to view your SaaS. Are they signing up for a service and choosing their features, or are they buying individual products provided by a service? It is an important distinction, and your cart strategy sets that expectation.

Lets say your service is called CloudGate. If you use a cart strategy, I assume I am buying a domain name, and CloudGate is on the back end setting up the license, etc. In the future if I want to add another domain I may return to CLoudGate, or I may hit up NameCheap and see if their pricing is better. I am not viewing you as a service, but as a shop where I can buy things. The benefit to this is that I can try out your products and maybe decide to become a brand advocate and do more shopping from you in the future. The negative is that I am still thinking about the products individually.

If you have me sign up for CloudGate as a service, and then choose options or features during the sign-up process (or by going into my account and turning them on), I am more likely to start with your service for adding additional features, because that is my system of choice. The benefit is that I view your products holistically, the drawback is that I need more assurance before I complete the initial sale.

Consider how you want to frame the conversation for users, and what your business requirements are. A la carte might lead to better short term success, good for a start-up perhaps, but subscription style could have long-term benefits, particularly if you're a somewhat entrenched player in the space.

Answer 2

The important thing to do here is to make sure you aren't disrupting the workflow for the user. If they want to add a domain, allow them to do so without getting distracted by a shopping cart process.

When they click the add domain link, show a hidden div that allows them to put any details in required to make and complete the purchase. Then hold that purchase (don't charge the card) for a few hours.

Upon completing the purchase, you can show them a browse store link. This way, the user's workflow isn't interrupted, but you have the opportunity to group the purchases that they make within a specified period of time. Obviously, this depends on your payment system and how skilled your dev team is, but it's not impossible (nor all that difficult) to do.

Also add a link to the primary nav for your SaaS app for the store so they can just browse through at their leisure when they aren't trying to complete a task.

Answer 3

To answer purely on analogies:

SaaS is comparable to a subscription service. Indeed I'll casually argue that most Saas is subscription oriented. Since they are intangible by-nature, they require renewal.

Shoppings carts are more typical to tangible items.

---

Subscription services tend to have application or setup processes, rather than checkouts.

Subscription services commonly have a place to manage your subscriptions. A customer service desk (hotel), is the classic metaphor here. Think also of a broker's desk.

The primary dimensions are:

1. Subscriptions / Services
2. Per-subscription setup / reconfiguration
3. Application docket or record (e.g. in the case of a loan)
4. Calendar (or expenses)
5. Payment Account(s)
6. Contact Information