When the customer can only send a photo

Abstract

A customer photographs something and asks whether it can be supplied. Somebody at the distributor then has to work out which catalogue item that actually is.

They wanted the answer faster. That was the brief, and on the face of it it's a search problem: make the catalogue easier to look through. What made it interesting is that the catalogue was already searchable. It just couldn't be searched by the only thing the customer had given them.

Problem

Text search works when you already know roughly what to type. The whole difficulty here is that nobody does.

A customer sends a picture precisely because they can't name the thing. They don't have the part number, they don't know the range, and often they don't know the words the industry uses for the features that distinguish one item from another. That isn't ignorance. It's the normal condition of being a customer.

And plenty of these products are near-identical. Two items sit side by side in the catalogue and differ in a detail that's obvious the moment you see it and almost impossible to write down. There's no search term for the difference, because nobody ever needed to name it out loud. You point at it.

So the request arrives as the one thing the catalogue has no name for.

Two things made that worse in practice. Photos don't turn up one at a time: a single quote can carry a stack of them, and every photo is the same unanswerable question asked again. And somebody is usually waiting. On a live enquiry there's a person mid-conversation expecting a reply, and a slow answer and no answer aren't far apart.

There's a third thing, and we only found it once we started looking properly at the catalogue rather than at the search. Some products had no photograph. Nobody had ever treated catalogue photography as anything more than presentation, so gaps in it had never cost anything. The moment pictures become the way things are found, a missing picture stops being a cosmetic gap and starts being an item that cannot be found at all.

That was the part they hadn't asked us about, and it changed what the project was.

Solution

We made the picture the query.

Someone submits a photo and gets back the closest items from the catalogue, ranked, each one linking straight through to its record. No description to compose, no part number to hunt for, no guessing at the right words. The thing you have is the thing you search with.

It runs two ways, because the two situations aren't the same one. A single photo is answered immediately, for the case where there's a person waiting on the other end of a conversation. A whole quote's worth of photos is handled in the background: the request is acknowledged straight away and answers arrive as they're ready, so nobody sits watching a spinner while a stack of images is worked through one by one.

It keeps itself current. As the catalogue changes, what can be found changes with it. There's no second copy of anything for somebody to remember to update, which matters more than it sounds, because the maintenance job nobody owns is the one that silently stops happening.

There's one deliberate asymmetry. On the live path, a person can still see what was asked. Not as a fallback bolted on afterwards, but because that's the path with a human waiting, and that's where a human might need to step in. The bulk path was built without it on purpose. Machines don't need somebody watching them work.

And the photography gap got treated as part of the work rather than as somebody else's problem, because a system that quietly can't find part of the catalogue is worse than one that visibly doesn't exist.

Nobody hunts through a catalogue by eye looking for a match any more. That was the job.