Home » eCommerce Blogs » B2B Portal Blogs » B2B Portal Case Study

B2B Portals Case Study:

Building a B2B web portal

eCommerce Development b2b portal
John O'rourke

10 Minute read September 2021

Table of Contents

b2b portal

About the Client

A UK-based manufacturer of bespoke plastic packaging, with factories in the North West and China, around 40 employees and a turnover of around £25m.

The Problem

To keep their large corporate customers in an ever more competitive market, our client realised that technology could help sell their plastic packaging products more effectively. With this in mind, they had to find a way to create a quicker, easier experience for customers, and also for staff. To make it even harder, their brand new stock control system did not have a built in ability to connect to a website.

The challenge: reduce manual work for the sales team, and provide customers with a simpler, quicker ordering experience.

The Solution

To design and build a portal that automatically pulls in product, customer and order data from the in-house system. It allows staff to decide which customers are given access, and which products they can see. Customers can quickly place orders which are automatically downloaded into the stock control system.


Maintenance Cost of £0
Orders Worth Over £10 million

Within a year, our client was able to have their flagship customers using the system, placing orders worth over £10m using the new system. Within three years the majority of their sales went through the system, and it had been enhanced to include new “user stories” that were based on the real experience of using the system. Over time, with ongoing work done in the right way, the stability of the system became so good that the maintenance costs became almost zero.

The Process

The Discovery Process

The first step is always discovery – we find out the details about what is needed, and what is possible. We interviewed staff, customers and the management team to understand what would provide the most value. Value can be in various forms, such as saving staff time or making complex processes less error-prone. In this case, the value was in saving sales staff time dealing with queries about orders, and saving admin staff time in keying in those orders. We also discovered that the larger customers had specific needs of their own, such as limiting the number of pallets of goods being delivered to certain addresses.

During the discovery process, we created a large set of “user stories” – short descriptions of an outcome that someone wants, like “I need to see the current stock level of my products”. A technical architect (someone who understands the business, the staff, and the technical elements) can then turn these user stories into “technical stories”, which are a more detailed description of what the software needs to do.

We produced a list of over 50 stories including requirements from the warehouse, the end customers, and the sales team, and split the work into 6 phases. By splitting up the work, it allowed the project to produce its first usable version within a few months, and then add further features based on that experience.

Building the Solution

At this stage, we had enough information and understanding to put prices on the first few months of work, and decide who needs to be involved in delivering the project. It’s important to recognise that larger projects can’t be fully priced, and a good agency will provide a price range, or indicative pricing, which can be adjusted later.

We then started building the system. It’s important to think about how the business can continue its day to day operations during this time, and in this case we needed to use a lot of the IT staff time to help connect the stock control system with the website. That had an impact on their ability to provide day to day support for the other staff, so we had to find a balance and manage everybody’s expectations around that.

Involve Everybody in Testing

Once the work is ready to test, everybody gets involved – for example, the management team may need to see the types of report that are produced, and the warehouse staff might need to see certain information on the sales orders. It’s really important at this stage to get everybody’s input, and really understand how the new system fits into their existing roles.

Launching the new System

In the next step, when the system is ready to be used, a process for migrating data from the old to the new system must be created, and tested – in this case, the website was new and so there was no old data to be migrated. Your data is one of the most valuable assets your business owns, so it’s important to know where it all is, and how it is secured.

Support and Maintenance

Finally, any technical system needs to be looked after. Software has “wear and tear” just like a car, so things need to be maintained or replaced over time. We use our past experience to estimate what is required – using the car example, we can judge whether the tyres will need replacing every 6 months or every 3 years, and price your maintenance accordingly. A well designed and built system will have lower maintenance and support costs, and allow you to grow – adding more customers, new features, and more value.

Would You like Some Expert Advice?

Contact Us
John Software Developer
Connect with Managing Director John