How We Automated Product Classification

We’ve built an n8n workflow that uses a low-cost AI model to work out the brand and device type of every new hardware product we buy, then feeds that straight into our finance and reporting platform. It runs unattended every weekday morning, and it exists to stop a new system from creating extra work. What would have cost us valuable senior leadership time each week, actually costs us pennies.

Why did we need to automate product classification?

Most of the automations we build start with an existing problem, a task that already costs us time and that we want to remove. This one was different. It came out of moving onto a new finance and reporting platform that works very differently to what we used before, and we built it before the new platform had even properly bedded in, to stop it creating an ongoing job we hadn’t factored in.

Our new platform needed far more detail about what we sell than we’d previously captured, not just how much revenue came from hardware, but the split between laptops, workstations and tablets, and within that, the split between brands and models. That level of detail matters for meeting our reporting requirements, but it means every new product needs to be correctly labelled in order to report accurately.

The trouble is, a brand new product doesn’t arrive labelled. Somebody has to look at it and decide.

What problem was this automation designed to solve?

Once a new hardware product is imported into our service desk platform from a supplier catalogue, it needs a specific brand and device type before it can flow through to our finance platform, and until that happens, the record is incomplete. Left unmanaged, this created a few distinct problems:

A manual step for every new product. Someone had to open each new product individually and map its brand and device type manually, roughly two to five minutes at a time, before it would sync through correctly.

Volume that never stayed still. A quiet week might bring a handful of new products, a busy one could bring dozens, and every single one needed the same manual attention regardless.

Failures that stayed invisible. If a product wasn’t mapped, nothing broke straight away. It just sat there incomplete until it mattered.

The gaps surfaced at the worst possible time. Missing data typically wasn’t noticed until the monthly invoice run, turning a routine close into a scramble to fix records that should already have been correct.

Only a couple of people could actually do it. Fixing it required both platform access and financial context, so it fell to a small number of senior people, exactly the people whose time costs the most.

How does the workflow actually work?

We built the fix in n8n. It runs unattended, early on weekday mornings, and works through the same steps each time:

It loads the current brand and device type lists directly from our finance platform, so it’s always working from exactly the same categories a person would use, and stays accurate as those lists change over time.
It clears its own working table before doing anything else, so it never wastes a run re-checking something already handled correctly.
It pulls a report of newly imported products that are still missing the fields our finance platform needs, checks for duplicates, and stores a snapshot of each one so it can be included in a weekly summary.
Each product’s name is passed to a small, low-cost AI model with one job only, read the name and choose a brand and device type from an approved list. It sees nothing else about the product, no pricing, no customer detail, which keeps its task, and its running cost, as small as possible.
The workflow uses that output to build an API call back into our service desk platform, updating each product’s record directly, and loops through however many products are waiting that day.

Much like our daily back-up check workflow, this one runs unattended on a schedule. In this case, it only needs a person’s attention once a week, on a Friday, when a short summary of everything processed lands in an inbox for a quick visual check.

Why did we use such a low-cost AI model?

A fixed lookup table wouldn’t have coped here. Brand and product names show up in dozens of variants, the same manufacturer can appear under several slightly different spellings, and a new model range can look nothing like the last one despite being the same type of device. A language model handles that kind of pattern-matching naturally, without needing to be manually updated every time a vendor changes how they name something.

What it doesn’t need is a powerful one. Deciding whether a product is a laptop or a network switch, and which brand made it, is a simple classification task, so we deliberately used one of the cheapest models available, priced in fractions of a penny per call, and kept its instructions and its inputs as narrow as possible. Controlling what goes in and what comes back out is what keeps a task like this cheap, more than the choice of model itself.

What access and safeguards did this need?

Getting this working meant API access to our service desk platform and a language model connected through n8n, which orchestrates the whole thing. A few deliberate choices keep it safe to run unattended:

Minimal data, minimal risk. The AI model only ever sees a product’s name, nothing about price, customer or account detail.

Nothing it does is destructive. Every field it sets can be corrected afterwards with no knock-on effect, so a wrong classification is an inconvenience, not a risk.

A human still checks the output. The weekly summary means every classification gets a visual review before it feeds into anything that matters.

The manual process still exists. If the workflow doesn’t run, or something looks off, staff can still map a product by hand exactly as before, so the automation is never the only route to a correct record.

What results have we seen so far?

In its first few weeks, the workflow got through the backlog with almost no manual involvement:

Before	After
Every new product needed two to five minutes of manual mapping before it would sync through	Classification happens automatically, unattended, within the same working day
Volume spiked unpredictably, and every product needed the same manual attention regardless	The workflow processes whatever volume arrives, on the same schedule, every weekday
Missing data usually surfaced during the monthly invoice run, at the worst possible time	A weekly summary flags anything worth a second look, well before it matters
Only a couple of senior people could do this work, pulling them away from higher-value tasks	Those same people now spend a few minutes a week checking a summary, rather than doing the mapping itself

How much did this cost, and what did it save?

Because this workflow was built to prevent a cost rather than remove an existing one, working out its return looks a little different to some of our other automations. The build took roughly three to four hours of engineering time. Running it costs pennies a day, and it’s already classified over 200 products so far in a matter of weeks without anyone touching them.

Measured against the time it would otherwise have taken, at two to five minutes per product, multiplied across dozens or more each week, and measured against who would otherwise have had to do that work, senior staff pulled away from tasks that actually need their expertise, the workflow had already paid back its own build time within its first few weeks. As we grow, the same logic scales: without it, this workload would increasingly draw down on internal staff time that’s better spent elsewhere, quietly becoming someone’s part-time job.

What did we learn from building this?

AI doesn’t need to be expensive to earn its keep. A narrow task, one input, one constrained output, can run on one of the cheapest models available and still be reliable.

Pull categories from the system that owns them. Loading brand and device lists from our finance platform on every run, rather than hard-coding them, means the workflow stays accurate as those lists change, without anyone needing to update it.

Prevention is a legitimate reason to automate. Not every workflow needs to remove pain that already exists. Some of the best ones stop a new system, or a new process, from creating pain in the first place.

Reversible tasks are the easiest ones to hand over. Because a wrong classification is easy to spot and cheap to fix, we were comfortable letting the workflow run and correct itself, with a human check on a weekly cadence rather than gating every single change.