Case record · Industrial B2B

B2B industrial catalogue website:
tools.narvyn.com

A carbide cutting-tool catalogue: more than 180 SKUs across six tool families, every one of them with its own indexable page. Four weeks from discovery to live, and most of its enquiries still arrive on WhatsApp.

Open tools.narvyn.com

Record NPT-01

The engineering record

Sector
Industrial B2B — carbide cutting tools
Live at
tools.narvyn.com
Stack
Next.js 14 (App Router) · TypeScript · Tailwind CSS · Typed catalogue modules · schema.org Product structured data
Timeline
4 weeks, discovery to live
What it carries
180+ SKUs across 6 tool families, each with its own page; around 1,800 sessions a month; most enquiries arrive on WhatsApp rather than the form

180+ pages, two decisions, one migration

tools.narvyn.com — the carbide tooling catalogue with product families and enquiry buttons
Six tool families at the top level. Under each one, a real page for every individual SKU rather than a filter that rearranges a single screen.
The briefwho is actually searching

Nobody searches for a category.

A buyer in this trade does not type “carbide cutting tools” into Google. They type a grade, a diameter, a flute count and a coating, usually in that order and usually with no spaces where you would expect them. They are trying to find one specific item, often to match something already sitting on a machine, and they are frequently doing it from a phone on a shop floor with a part in their other hand.

That single observation determined the architecture. There are two ways to build a 180-SKU catalogue. The common one is a single catalogue screen with filters: pick a family, narrow by diameter, narrow by grade, and the list rearranges itself. It looks modern, it demos well, and it is invisible to search — because every one of those combinations lives at the same address, or at an address that only exists once a person has clicked. There is no page for a search engine to rank, and nothing to send a customer as a link.

The second way is more work and it is the one this site uses. Every SKU is a real page, at its own URL, in the HTML before any JavaScript runs. It costs more to build and considerably more to keep tidy. It is also the only version of this website that can answer the search the buyer actually performs.

Decisionsthe choice, the reason, and the consequence

Two calls that made the difference.

Decision 01

Every SKU gets a real, indexable page rather than a filter state on one catalogue screen.

Why

Buyers search for a specific grade and diameter, not for a category. A page per SKU is the only version of this site that can answer that search.

What it means in practice

A page per SKU turns one competitive term into 180 specific ones. No single one of them carries much volume — a handful of searches a month at best — but they carry almost pure intent, because a person searching a grade and a diameter is not researching. They are buying, or checking whether they can.

It also changes what happens off the website. A salesperson can send one link that opens on exactly the right item, with the specification visible, instead of a PDF and a page number. That is a small thing that gets used every day, which is usually the definition of a good decision.

The cost is discipline. 180 pages of thin, duplicated boilerplate would be worse than one good catalogue screen, so each page has to carry its own specification detail. Structured product data helps search engines understand what each page describes, but it does not rescue a page with nothing on it.

Decision 02

Enquiry buttons open WhatsApp with the SKU code already written into the message.

Why

This trade runs on WhatsApp. Removing the step where a buyer retypes a part number removed the step where the part number is wrong.

What it means in practice

This is the least clever thing on the site and probably the most valuable. The enquiry button on a SKU page opens WhatsApp with the part code already in the message body. The buyer adds a quantity and sends it.

Two failure modes disappear at once. The first is the retyped part number, which in a trade full of codes like a single transposed digit is a real source of wrong quotes and wrong deliveries. The second is abandonment: a six-field form on a shop floor is a decision to come back later, and later rarely arrives.

It is worth being honest about the trade-off, because it is not free. A WhatsApp enquiry does not land in a database with a source and a timestamp the way a form submission does, so the analytics get blurrier. For this client that was the right exchange — the enquiries are real conversations with a person who knows the products. A business that needs every lead attributed to a campaign should think harder, and probably wants a CRM catching both channels rather than a choice between them.

The numbersand the one we cannot measure

Around 1,800 sessions a month.

Roughly 1,800 sessions a month across a catalogue of 180-plus items, with most enquiries arriving on WhatsApp rather than through the form. That second half of the sentence is the interesting one, and it is also the reason we cannot give you a clean conversion rate for this site.

We know how many people reach a SKU page and we know how many tap the enquiry button. What happens after that is a conversation on somebody's phone. We could have insisted on a form to keep the numbers tidy, and the numbers would have looked better while the business did worse. Choosing the channel the trade already uses over the channel that reports nicely is a decision we would make again, and it is the kind of decision that never appears in a case study written by a marketing department.

For anyone comparing: 1,800 sessions is a small number in absolute terms and a healthy one for a specialised industrial catalogue in a narrow niche. Traffic to a page about a specific tool grade is never going to be large. It is going to be relevant, which is a different and more useful property.

Measured

Month to month

Sessions
~1,800 a month
Catalogue
180+ SKUs, 6 families
Pages per SKU
One, indexable
Main enquiry channel
WhatsApp, pre-filled
Build
4 weeks, discovery to live

the tidy metric was the wrong metric

What we got wrongit cost a migration

Grade and tolerance began life as free text.

Grade and tolerance started life as free text; making them structured fields later cost a migration we could have avoided by asking one more question up front.

Free text is seductive at the start of a catalogue build because it accepts everything and blocks nothing. You can enter the first fifty products in an afternoon. The bill arrives the first time somebody asks a question the data cannot answer — in this case, “show me everything in this grade” and “sort these by tolerance.” A field that holds text can be displayed. It cannot be filtered, compared or reliably grouped, because the same value has been written six slightly different ways across 180 records.

Converting afterwards is not a schema change. It is reading every existing record, deciding what each written value was meant to say, agreeing the canonical list with the client, migrating the data and then re-checking it — work that produces no visible improvement to anybody looking at the site.

The lesson generalises past catalogues, and it is now a fixed question in our discovery: which attributes will someone eventually want to filter, sort or group by? Those are not descriptions. They are structured fields, with a list of permitted values agreed before the first record is entered. Everything else can be free text safely. Getting that question asked at the right moment is most of what data modelling on a custom build actually is.

If you are planning onefour questions, answered before the quote

What decides the size of this job.

How many SKUs, honestly

Not families — individual items. Fifty and five hundred are different projects, and the difference is data preparation rather than development.

Where the specs live now

A clean spreadsheet is a good day. A print catalogue PDF means someone types every specification and someone else checks it. Budget for both.

Which fields get filtered

Decide this before entry, not after. It is the difference between a structured field and the migration described above.

Where enquiries should land

WhatsApp, a form, a shared inbox or a pipeline. It changes the build, and it changes what you can measure afterwards.

Those four answers move a catalogue quote further than any technology choice does. If you want the general version of that argument, it is set out on how we cost a build.

Got a product list nobody
can search?

Send the catalogue in whatever state it is in — spreadsheet, PDF or printed book. We will tell you what structure it needs before we talk about cost.

no commitment required · we reply within 24 hours