Weldmet

Consulting as a Solutions Engineer

Built with

The Problem

When the pandemic struck in early 2020, my dad's welding supplies business faced a difficult situation. Although the business had been running for over 25 years with email and telephone, it was not set up to handle online sales. Their website at the time was a catalogue-style site from 2005, that had no payment processing or ordering functionality. This presented some challenges:

  • Products lacked up-to-date information (documentation, images, manufacturer information and in some cases, even prices).
  • Order handling, payment collection and fulfillment was error-prone and inefficient.
  • Customers had to place orders over the phone, but with staff shortages, this was slowing the business down.

To help out my family's business during the pandemic, I undertook the task of building an online store to serve customers safely. In this article, I'll share why and how I also ended up building over a dozen internal applications to support this digital transformation.

Picking an eCommerce Platform

Lacking a good understanding of the current B2B eCommerce landscape, I started out by digging through a number of articles and books that I found on Amazon. After sifting through a fair amount of 'billion dollar eCommerce growth hacks' and tactical playbooks, I found B2B eCommerce Masterplan by Chloë Thomas. Her perspective was refreshing and intuitive:

"B2B buyers are humans too"

Online B2B businesses, she advises, should therefore strive to match the convenience of B2C online shopping experiences (Amazon, ASOS, John Lewis etc.) their customers will be using during their off-hours.

With that goal in mind, I began evaluating leading eCommerce platforms with a strong B2C focus, my criteria also included:

  • Comprehensive and well-documented API
  • Sensible pricing for SME (TCO < £1,000 p/m)
  • Well-designed theme to serve as a starting point for customization

Among others, Odoo was a contender but I soon realised that its eCommerce module required using all of their other modules too, and would require a replatforming all of Weldmet's backend systems (a mammoth project in its own right). Being a team of one, I needed to focus on adding a storefront, not a wholesale backend migration. In terms of developer tooling, pricing and high-profile B2C customers, the clear winner was Shopify.

Although it is most often used as an end-to-end platform, Shopify also allows for the flexibility of functioning merely as a storefront. Its 'batteries included' philosophy meant I could direct my efforts towards developing a two-way integration, facilitating data transfer between Shopify and the legacy ERP.

Navigating the Integration Maze: A Story of Two APIs

The next task at hand was to establish a two-way integration. This was essential because the legacy ERP system, Hansa, needed to provide updates about its products, and Shopify, in return, had to relay orders to Hansa. Working with Shopify was a largely delightful experience, but Hansa left much to be desired:

  • No staging environment, nor even a licensing allowance for a duplicate 'development' instance.
  • Dispatches malformed XML that required treatment and wrapping before any parser could process it.
  • A mere 3 pages of sparse documentation.
  • Lack of webhooks, so all changes must be detected from polling

Fortunately, once I had scoped out most of the quirks of the API, I sealed those horrors inside a plain old Ruby object and exposed a more rational set of methods for ongoing development. To keep an eye on things, the first internal tool I built for Weldmet simply monitored the state of the integration, and surfaced event data. In conjunction with Sentry, this helped me to react quickly to unforeseen edge cases that would have otherwise been prevented through adequate documentation and the availability of a staging environment in Hansa.

Enhancing Product Information

Once the large inventory of over 5,000 products was synchronized from the ERP, products on the store started out with only the most basic information (title and price). It was crucial to devise a method to categorize, manage and enrich these products. Although there are many 'Product Information Management' (PIM) tools that could help with this, such as Akeneo, PIMs are typically expensive, complex tools to adopt and overkill for our requirements.

Instead, I opted to create a suite of internal apps to manage frequent product-related tasks, dubbed the "Weldmet Toolbox". For instance, one app was designed to associate manufacturer branding with each product, automatically tagged by the presence of brand-specific keywords:

On the storefront, banners are then shown on each of the brand's products like this:

I found myself employing the same pattern for many different apps, to take advantage of Shopify's caching mechanism: setting metafields in Shopify via the API, and using these values in the Liquid templates rendered by Shopify. For example, to show product documentation, PDFs can be attached within the Items app in the Weldmet Toolbox. These documents are then uploaded to AWS S3 and stored in a list-type metafield on the product, to be shown like this:

Monitoring Price Adjustments

Another painful and long-standing product information problem in Weldmet was updating prices. Suppliers would revise their product prices every quarter, typically providing just a spreadsheet containing the part number and the new recommended retail price (RRP). The predicament here is that Hansa lacked a field for manufacturer part number (MPN), so Weldmet staff had stored this information variably within the product title, description, or occasionally not at all.

To address this, I developed a tool allowing staff to upload a basic CSV file. The system then attempts to match the manufacturer's code using regular expressions that correspond with their part number schema. Staff are presented with a list of suggested price changes, which they can then accept, modify, reject, or defer in batches. This solution has slashed the time spent on this task each quarter from three days to just one.

Streamlining Order Management

Following a surge in new orders post-launch, my focus shifted towards order fulfillment, which was struggling to keep pace. Conversations with the warehouse staff revealed that many mistakes and inefficiencies stemmed from the absence of a definitive source of truth for an order's status. Since orders are placed not only through the new online store, but also directly into the ERP, we weren't able to make full use of Shopify's admin as the source of truth for orders. To consolidate web and offline orders, I created a control panel to manage them all in one UI. We were then able to search, sort and track any order through its journey:

  • To be picked
  • To be dispatched
  • Dispatched

The Travelling Salesman Dilemma

One of the ways that Weldmet delivers goods to customers is with their fleet of drivers. Each morning, the drivers at Weldmet consider the deliveries for the day, debate who should go where and plan their route on paper using their knowledge of the local area. This task could consume up to an hour each morning, as deliveries were shuffled around.

Seeing an opportunity, I designed a tool enabling the logistics manager to assign deliveries to each driver and visualize their proposed routes on a Google map. The tool also allows for reordering stops, predicting arrival times, and optimizing the route automatically The finalized route is then provided as a printable document for the driver's reference.

To achieve this, I developed a separate Flask API in Python on AWS Lambda (deployed with the Serverless Framework). It utilizes the Google Maps Distance Matrix API to calculate the distance between each stop, and OR-Tools to provide an initial solution to the Travelling Salesman Problem. The tool is now a daily fixture for the logistics manager, reducing route planning time from an hour to mere minutes.

Results

Although the site has been live for only six months at the time of writing, the early indicators for Weldmet are encouraging.

  • Online sales have seen a 305% growth in the last quarter.
  • The average fulfillment time for UK-based orders has dropped from 3.2 to 2.5 working days since the introduction of the new tools.

Learnings

Reflecting on the past six months, here are a few insights that may prove valuable to others seeking to assist a small business:

  • Treat internal tool launches like public ones. Brand your tools. Proactively and continually seek out feedback from your end users (colleagues), especially during their first two weeks of using the new application. This period is the make or break for adoption. Listen and react quickly to their feedback, and they'll likely become champions for your tool within the department.
  • Pick one battle at a time. With your engineer's hat on, you may feel a strong urge to 'rip out' a legacy piece of software (as I have often been tempted to), and update it with something newer. However, resist that urge while there are more immediate shortcomings in the business. Legacy systems can be supported and encapsulated behind a more user-friendly API until resources are available for a full replacement.
  • Always design tools as if the number of editable entities is 10,000. As I've mentioned before, ergonomics (keyboard-first design, batch operations) are often neglected in software design. It's a uniquely great feeling to see a colleague bounce around with excitement after flying through a task that used to take several days of mind-numbing data entry.