Case Study: WisePorter and the eCommerce client

This case study describes an ongoing project. The identity of the client, as well as some details about the project, must be kept confidential for the time being, but we will be happy to show it off as soon as possible.

For this case study, we have selected three specific problems of the original solution identified by the client in the pre-project analysis and described how these problems are solved using WisePorter.

The client and his background

The client is one of the largest Czech eCommerce companies, owner of several e-shops, which sells goods to retail and wholesale customers. The company provides basic services such as transport, service or assembly. The goods are supplied by a combination of own stock and direct deliveries from subcontractors (dropshipping).

The buyer defines the rules and sets the required margin. Based on this, WisePorter decides whether to cover the end customer’s order from its own warehouse or by buying directly from a supplier. WisePorter Smart Product Catalog takes into account the financial cost of each option, as well as the speed of delivery, for example, or any other parameter that the buyer considers in its rules.

To make matters worse, a large part of the goods is subject to strong seasonality (summer, winter, Christmas, etc.). Goods are also traded on foreign markets, so languages, multi-currency pricing and independent pricing for individual countries come into play. That’s a lot of highly variable data that needs to be handled with care! And such care requires quite a decent IT background, which the client lacked. As it happens, his core business is selling, not programming.

The client uses one of the most common Czech ERP systems, from which e-shops drew data for sales. However, this had caused problems with product management, as the ERP system is principally focused on logistics and accounting. Individual e-shops run on several different platforms with different functionalities. However, there was no one place where all product sales parameters could be set up and reliably fed into the individual e-shops. So the daily routine involved processing a large number of excel spreadsheets and, especially during peak seasons, a huge amount of manual intervention to make corrections and transfer data between systems.

Working with product parameters

Original client situation

The products were managed in the ERP focused on warehousing and accounting, not sales. Therefore the ERP did not allow many important sales parameters to be entered – for example, commercial names and texts, HTML formatting, images, SEO settings, etc. The client addressed the sales parameters partly in the eCommerce configuration and partly in other applications outside the ERP.

The situation was also complicated by the fact that the client has several different e-shops (for different types of goods and different territories) – each on a different platform/framework. Everything in the ERP applied to all e-shops and could not be easily changed for a particular e-shop, and vice versa: what was not in the ERP was entered at the individual e-shop level – often repeatedly and inconsistently.

→ The consequence of this situation was many inconsistent sources of product information, a difficult process of entering and changing products, complicated and time-consuming work for users, synchronization errors and, as a result, inaccurate information for customers on the e-shop.

→ The original state on the one hand caused the unnecessary use of inaccurate values (so that they could be entered once universally in the ERP and used for all e-shops), and on the other hand, it entailed a lot of unnecessary manual work when entering the same information not contained in the ERP for each e-shop separately.

→ The goal was simple: to enter all common information across sales channels only once and thus reduce the error rate. On the contrary, the information that differs for each sales channel should be set up in such a way that users (e-shop administrators) can distinguish it and work with it individually.

You can read more about where the use of ERP instead of a Product Inventory Management (PIM) leads to in our article Why do we need a Smart Product Catalog?

How WisePorter helped

WisePorter Smart Product Catalog distinguishes between:

1. product specification – a general description of the product and its parameters, independent of the method of sale. Typically dimensions, colour, weight, manufacturer, etc.
2. product offer – product parameters related to its sale, typically wording, images, SEO settings, sales prices and promotions, available shipping methods or local services, etc.

→ This allows product managers to enter common information only once, and channel-specific information as subtle as they need. Working with the product base is more efficient and sales are more precisely targeted.

We use a product categorization. Parameters common for the whole product category only need to be defined once, they are automatically transferred to all products in the category. Product categories form a hierarchy (created exactly according to the client’s needs) and parameters can be added or changed at any level of this hierarchy.

We also work with the product variants. For example, if there is a product line with multiple options by colour, size or other criteria, the common parameters are defined only once and only what is different for the variant is specified.

→ Thanks to this, producers can describe products very precisely, with only the parameters that belong to them. The data is of high quality because one entry is entered only once, in a controlled way, with dials and validations, in a clear structure. The work is faster and the result contains fewer errors.

The product has a rich structure of basic parameters, images, classic and HTML texts, links to other products, available services, options to create packages and sets, etc.

→ This gives the e-shop operator a wide range of options to make the offer as close to the customer as possible.

→ Future expansion into a new market or replacing a current e-shop solution with another, is a relatively simple matter, as all e-shops draw product data from one central source of truth.

Pricing

The client’s original situation

This is something every online shop knows – if you have multiple suppliers, you have to work with differently processed offers. And to make matters worse, there are also multiple ways to get those offers from a supplier:

1. by email from the supplier,
2. you download them yourself from the supplier’s website,
3. you download them from the supplier’s FTP server,
4. the vendor is actively calling your API.

Each supplier’s offer has a different structure and different semantics. Price interpretation varies widely between suppliers – sometimes prices include shipping, sometimes not, sometimes include bonuses and discounts, etc.

The price from the supplier’s offer is often not the actual cost of the e-shop operator – it does not include, for example, quantity discounts, exchange rate settlements, etc.

→ The client thus needs a huge amount of excel spreadsheets and manual work to calculate what is actually his cost when using the offer of a particular supplier.

→ The consequence is error rates, human costs, slow response to price changes and inaccurate pricing, where unnecessarily expensive or unnecessarily cheap sales are made.

→ It is not easy to compare suppliers’ offers and select the most suitable offer for purchase.

→ Without accurate knowledge of the cost price, it is not possible to set the selling price correctly and maintain the required margin.

How WisePorter helped

WisePorter Smart Product Catalogue automatically downloads quotes from suppliers. In addition, pricing rules can be linked to them, which automatically calculate cost prices, margin, profitability, the profitability of a given supplier according to various criteria and so on. The rules can be set differently for different suppliers to take into account the specifics of the supplier’s bids.

→ The result of the whole process of importing quotations is then a standardized cost price, which allows direct comparison of quotations across suppliers and also across different delivery methods (own warehouse versus dropshipping). This allows a small group of buyers to easily make decisions on a huge range of goods for sale.

Based on the purchase price and pricing rules, sales prices for individual sales channels are automatically calculated, again with continuous monitoring of margin, profitability or discount space.

→ With the help of the Smart Product Catalog automation, the product manager has a system that handles the routine on both the buying and selling side. But at the same time, according to defined rules, it immediately alerts him to non-standard situations that require control or intervention.

→ Pricing rules are set directly by product managers and pricing changes do not require the involvement of programmers. This gives the sales team unlimited room to fine-tune the pricing strategy.

→ Thanks to this automation, the client saves about 600 man-hours of work per month, which in the past required manual checking of new offers and constant recalculation of excel tables with prices.

Stocking

Original client situation

In addition to prices, suppliers also send stock levels. Stock levels change very quickly. If the updated information does not get to the e-shops automatically, it happens that the e-shop operator sells something to his client that he is no longer able to supply by dropshipping (or supply at the price indicated).

→ The consequence is a damaged reputation with customers and financial losses due to incorrect pricing.

How WisePorter helped

Stock availability from suppliers and internal stock levels can be downloaded automatically. The availability displayed on the e-shops and the offered selling price of the goods immediately reflect the current availability of the goods in the warehouses.

→ This avoids situations where the client orders goods that are no longer available according to the information on the e-shop.

→ It is possible, for example, to automatically end a promotion or increase the price when the stock is low.

→ Individual warehouses are recorded separately. This makes it possible to have different prices in different countries depending on the local availability of goods.