What we learnt from the Commerce early access survey

We recently sent out a survey to the folks who had signed up to test Commerce. The goal of the survey was to help assign priorities to the remaining work before the alpha release. We've had 56 responses, so thanks to everyone that filled it in.

In this post, I'll share some of the more interesting results and how those will affect Commerce's development.

Expectations for early access

The first question allowed people to select multiple items from a list of features they expected to be available in the alpha release. The following shows the available options and how many people chose that answer:

1. stock/inventory related functionality: 39 votes
2. a wide selection of payment gateways: 38 votes
3. discount/coupon code related functionality: 30 votes
4. in-depth documentation on the internals of Commerce for developing modules/integrations: 30 votes
5. a white-label end-user guide for managing the shop: 22 votes
6. integration with shipping partners: 16 votes
7. integration with CRM systems: 11 votes

There's obviously a ton more features that could've been on this list. What surprised me the most was the popularity for stock/inventory related functionality. Based on the response, it seems more important than I originally expected.

Payment gateways

When asked which payment gateways people expected to need, 88% answered PayPal. This was expected and, in fact, is already a gateway we've implemented. Stripe was second with 55% and Authorize.net was third with 32%. SagePay was the next most popular with 21%, which incidentally is also the most requested payment gateway for SimpleCart.

The other gateways were Sofort (18%), WordPay (16%), BrainTree (13%), Ogone (13%), Mollie (9%), Moneris (7%), Postfinance (5%), WireCard (4%) and PayPro (2%), Sisow (2%), IcePay (2%), and AsiaPay (2%).

For the v1 release, we'll focus on supporting gateways with 10% or more of the votes (PayPal, Stripe, Authorize.net, SagePay, Sofort, WorldPay, Braintree, Ogone and Mollie). Eventually we'd like to support all of the payment gateways requested.

Interactive Status Builder & Theme Editor

The survey pitched 2 features I'd like to add but have been considering pushing back get Commerce released sooner. To see how important these features were, we asked people to rate it from 1 (not important to me) to 5 (very important to me).

The first one was an interactive status workflow builder, which would allow you to use a visual tool to manage how orders flow from one status to the next. The average result of 3.04 indicates people think it would be useful but not critical.

Based on this response, the status builder won't make the alpha but I will try to add it in time for the stable release.

The second feature was a theme editor in the manager. As Commerce uses file-based Twig templates, these are primarily edited on the filesystem. The proposed feature would add a place where these files can be edited on the fly, with some additional bells and whistles to make managing different themes easier.

The response to this question shows just how broad our user base is, with backend developers that are happy to work on the filesystem to site builders and developers that prefer having things in the manager. As the overall votes go more in the direction of Not important to me, we'll push this feature back to a later update.

Pricing

Recently we announced the price for Commerce (€299 including a year of support, lifetime bug-fix and feature releases, payment gateways and standard modules at no extra cost, as well as free development usage). In the survey we asked people if they thought that price was fair.

This is obviously a tricky question as people haven't had a chance to try it out, and all they know about Commerce is what we've told them so far (which to be fair isn't a lot). Nonetheless, I'm rather pleased with the way people answered this question:

• I'm not sure yet, will need to evaluate the product in more detail first: 64%
• Yes, that seems fair: 30%
• No, that price is just too high for my projects: 5%

Putting the right price on any product is really tricky. For a segment like ecommerce it's even harder, as the use cases will range from non-profit organisations accepting single-digit donations to luxury brands selling watches worth thousands of euros. With only 5% of the respondents indicating the price is too high and 30% thinking it's fair without having evaluated the product in detail, I think we're pretty close to the optimal price point.

Documentation

We also asked about the different types of documentation people would be looking for. We asked people to rate the following types of documentation on a scale from 1 (not important to me) to 5 (very important to me).

• Textual documentation for shop builders / front-end developers: average of 4.48
• Videos/screencast material for shop builders / front-end developers: average of 2.89
• Textual documentation on extending Commerce for back-end developers: average of 3.88
• Video/screencast material discussing the way Commerce works internally for back-end developers: average of 2.75
• Textual/visual white-label user guides for end-users, accessible from the Commerce dashboard: average 3.37

These results are roughly as I would've expected them, with textual documentation preferred over video/screencasts, and front-end documentation being more important than back-end documentation, which in turn is more important than end-user documentation.

Further comments

At the end of the survey we added a blank textfield for people to enter questions and other remarks they want us to know. Some comments were expected and echoed what we've been hearing in support (like "What's taking so long?" and "Looking forward to trying it out!"), but there were also great feature requests we hadn't considered yet (for example ability to add attachments to confirmation emails) and remarks that are worth repeating and commenting on here.

Focus on the core features of building a shop. IE Product details and inventory, taking orders (cart) and accepting payments. Everything else is secondary. Trying to integrate with other third party services will take forever. Don't try and be all things to all people. People will already have their own favourite CRM, marketing and other systems. You can work on that after you've built the core functionality and feature set.

It's great to read a comment like this, as it's exactly the direction we're going on. The core of Commerce will be rather limited, however it's the modules (a bunch of which will be included in the download) that add the additional features. These modules can be enabled and disabled through the dashboard, and developers can extend existing modules, or create new ones and load them as needed. In the survey we did ask what (if any) CRM people use to get an idea of demand for such integrations, but as the results for that are too varied it's unlikely we'll add any of those for v1.

Can't wait until I get my hands on an early release! :-)
I am little concerned about this product because of the very long delay of release after pronouncing the product.
Looking forward to the flexibility this sounds like it will provide!
What's taking so long!? ;) Look forward to seeing some demos soon.
Cannot wait to see this product so I can stop using WooCommerce!

We've definitely missed our original timeline by a landslide. It's easy to pinpoint reasons for that in hindsight, and there's definitely things I'd do differently if only I had a time machine, but that doesn't help get the project to a state where we can send you an invite!

The current schedule for Commerce is to send the first couple of invites around the end of the year. This will be the alpha product which is not yet complete, may have breaking changes in updates, but it should be a useable product.

As soon as we've sent the first invites for the alpha, we'll publish a detailed roadmap showing where we are in terms of completed features and known issues. This roadmap will be updated regularly. More and more people will receive an invite in Q1 2017 as we complete the items on the roadmap and fix bugs. With that timeline, we should have the first stable release 1.0 release in Q2 2017. To make that happen, I've stopped taking on freelance projects and I've enlisted more help so we can keep up the pace better than we have over the past year.