Woolworths at Work is a new division of Woolworths set up as a B2B-specific alternative to Woolworths Online.
One of the benefits Woolworths at Work gave certain suppliers were advertisements they'd run on their E-Commerce website. These advertisements ran for ~ 1 month, and featured some assets and a selection of products. Those ads would then link through to a page showing the full range of products from that supplier within the same general category - e.g. deserts.
The existing process
The process of setting up these advertisements was manual and time consuming. Being based around Google Sheets, it involved a lot of manual data entry, was prone to errors, and was difficult to manage. It was also difficult to track the progress of the setup, and to ensure that all the assets and products were set up correctly.
Due to constraints like not showing two desert ads at the same time, it also required quite a bit of back and forth with vendors until an appropriate schedule could be agreed upon. Each vendor would have their own Google sheet that set out their entitlements, and the details of the ads they wanted to run.
This process, like so many others, had grown organically from the time when the business was small, and scaling it up had proven extremely problematic. By the time we stepped in, managing this process was someone's full-time job.
The LiveView solution
We didn't want to roll out a new process and application all at once - disrupting the suppliers would have required a lot of change management that the business didn't have an appetite for at the time. So the solution we built tried to keep as much of the supplier-facing side as similar as possible.
We ended up building a LiveView application that automated almost all the manual work required for the process to run. The system held it's state in a Postgres database, and provided a UI to internal staff to manage various elements (supplier entitlements, products etc.). The system was integrated into the (separate) products database to make sure we were using up-to-date product catalogs.
The system ran on a custom Kubernetes cluster running on GCP. It was integrated into a BigQuery database, and a Postgres database also running in the same GCP Project.
Google sheets integration
The supplier-facing side of the application still leveraged Google sheets. It managed ~80 sheets in total - or approx. 1 per supplier.
Those sheets acted as essentially a UI for our application. Whenever suppliers made changes to their respective sheets, we would ingest those changes into the application. And whenever the application state changed, updates would be written back to the respective sheet.
We did make a few enhancements to those sheets as part of our build. The sheets all used a standardised template and formatting, had field validations & protections, and data validations on all inputs. These changes meant the frequency of 'bad' supplier input - which had been a common and time-consuming issue - was almost totally resolved.
Outcomes
This process went from consuming almost 1 FTE, to being a minor task that was only done once per month. It also provided a significantly better experience for suppliers, as it reduced their effort in scheduling these assets by properly validating their input, and providing better feedback around changes.