Increasing revenue through B2B - Business units

commercetools is a composable commerce platform that provides tools for commerce platforms to build faster, while choosing only components that are useful for their business.

Starting 2022, analysts recognised commercetools as a leader in B2B (while not having any B2B functionality), this was because of the extreme flexibility of the platform, that allowed vendors build custom solutions on top.

The business goals were now set to implement core B2B features to expand the total addressable. market and increase revenue through B2B.

One of the core B2B features which was outlined was business units. This was what my team and I worked on.

UX Research, user interviews, product design, usability testing

1 designer, 1 PM, 6 engineers

June 2022 - August 2023

B2B platforms need to facilitate transactions in the best way possible between their customers (which are also companies). To do this, they need the ability to create business units, modelled into a hierarchical structure modelling of companies and divisions. This will help improving the assignment and management of Customers within the business units for efficient handling of Carts, Orders, and Quotes, and providing a seamless integration with Stores to enable accurate representation of company-specific products and pricing.

Some earIy research was done before I joined the team:

Identifying the B2B target customer segments drilled down to business models - Manufacturers, wholesale, B2B2C.

Mapped out B2B assumptions collected form multiple stakeholders.

B2B competitor research to see how other platforms implemented the business units feature.

Customer interviews with partners to learn more about their experiences.

With the above information, I tried to map out a user flow, following the journey of how a user should navigate the feature.

The API’s were already implemented to an extent, so I studied the docs and used it to map put a kind of information architecture following the feilds listed on the docs. This raised some open questions that were then addressed with the team.

The next step was to create wireframes from the mapped out flows.

I created a tab structured menu (following existing design patterns on the platform)- General details, Associates and Addresses.

We dropped the possibility of having a tree structure showing the hiearchy of business units. This was done after estimating the effort/impact ratio.

We decided to create two roles for each Associate in a business unit. Admin and Buyer. Soon enough we realised that this was not enough considering how complex B2B use cases can be.

This forced us to go back and explore how to offer a more granular set of roles for our customers.

B2B Customers need more flexibility than just buyer and admin roles to effectively manage access rights of its buyers in order to be able to perform their business activities. This needs to be flexible to cover the wide range seen in how different B2B models and projects work.

After defining what our assumptions were, the next thing I did was to have a UX discovery session with everyone on the team. These were what we did and achived in the session:

Everyone listed the assumptions they had around the feature to ensure everyone was on the same page.

We then presented the problem statement - redefining it to make sure that everyone agreed with it.

We then listed out need to knows (questions we wanted to answer) and need to haves (actionable deliverables to help answer these questions)

For the UX side I was to do some competition analysis and user interviews to better understand, how other platforms handled granular roles/ permissions, and what our users expect with their unique use cases.

Below is a summary of findings from 3 platforms on how they handles granunalr roles and permissions.

I then conducted user interviews with 5 customers, these were some of the questions I asked them:

Who controls the access to roles and permissions?

What kind of permissions do you require?

How frequently roles and permissions are managed?

Would you use custom permissions?

Does inheritance apply to your roles/permissions?

The insights were interesing, but thankfully not so diverse from some of the assumptions we had, here are some of the insights:

Users need an interface to effectively manage roles and permissions.

Users want permissions mapped to roles and then assigned to a user.

Users want a central location to manage their roles and permissions.

Users want predefined global roles, and then default roles that can be modified.

Users want inheritance for roles and permissions but should have limits for controlling access to sensitive information e.g prices.

With all of the information gathered, I created user personas for the different kinds of users that would have to interact with the business units feature (and another feature meant for our team domain).

The next step I took was to collaborate with one of the engineers to map out a user flow for how a user can interact with creating and managing granular roles and permissions.

Then I drew up wireframes covering creation , editing and deleting of associate roles. Other things include management of the long list of permissions.

We reached out to same customers that were part of the user interviews for usability testing. I was able to test with 4 customers and 3 internal volunteers in the company. The goal at this point was to have them try the features and share feedback. Some of the insights we got were interesting. We made some changes in the UI to reflect these feedback.

We added the ability to toggle inheritance on business unit. When turned on the business unit can inherit associates from its parent business unit.

We introduced two states for an associate role: Explicit and Inherited. An explicit role is defined at the specific business unit level, while an inherited role comes from a parent business unit.

The final screens

projections for 2023 - € 5 million

sales as at Q3 - 2023 - € 9 million +

One of the problems we had was getting customers to test and try out the new features. It costs them time, resources and possibly some changes on their business model to be able to try our new features.

We had challenged with tracking, metrics and data, especially because there ws no platfrom wide solution.

While creating the solution, we have to consider dependencies and how business units would work with existing entities in the platform like orders, carts, quotes, stores etc.