Savdo: how an answer to a buyer is assembled from the shop's catalogue
A buyer writes into a messenger in their own words. The answer is assembled not from general knowledge but from the shop's catalogue, and before it goes out it is checked whether the size they need is in stock.
savdo.app is open, access to the system is by invitation
What a person sees
Three screens: the flow of conversations, the data the answer rests on, and how a dialogue passes to an operator.
This is a workplace, not a showcase dialogue: conversations come in a flow, each with its own age and its own state. Channels are not spread across separate apps, they converge into one list, and the filter at the top splits it by where the person wrote from.
The catalogue is the single source of truth. Price, stock and product variants live in it, and the answer to the buyer is built on them, not on whatever was memorised during training. If a size is not in stock, it will not make it into the answer: the check happens before the buyer sees anything.
Handing a dialogue to a person is the normal mode, not an emergency exit. The agent is switched off on any single dialogue with one toggle, and the next message goes out from the operator into the very same thread: no separate tool, and no asking the buyer to write somewhere else. The person sees the conversation continue, not a change of interlocutor.
What sits underneath
- Where the data comes from. The shop's catalogue: names, descriptions, prices, stock and product variants. Nothing but that makes it into an answer, and it is updated on the shop's side, not ours.
- What the system does. It breaks the question down into product features, budget and size, searches the catalogue for a match, checks the variants of each item for availability, and assembles an answer from what it found. The steps are visible in the conversation, not hidden.
- Where the limits are. This is not a replacement for a salesperson and not automatic selling: a person places the order. What is not in the catalogue will not be in the answer, and a difficult conversation is handed to the operator.
Where it got hard
Three forks at which the product could have become the thing we did not want it to be. Each one has its cost of getting it wrong.
cost of getting it wrongthe buyer was promised a size that does not exist, and it is the shop that deals with it
You can tell a smooth story about trainers without a catalogue, and it will sound convincing. Right up to the moment someone comes in for a pair that is not in the warehouse.
So a catalogue search comes before the answer, and for every item found the variants are checked: is it the right size and is it in stock. If it does not add up, the item does not make it into the answer at all, rather than being mentioned with a caveat.
cost of getting it wrongthe conversation goes the wrong way and the operator can only watch
Automated correspondence breaks not on hard questions but on the ones that need a decision: a discount, an exchange, a delivery date, an unhappy buyer.
The toggle sits on every dialogue, not in the general settings, and after it the input field is the same one. The operator does not move the conversation anywhere: the channel, the history and the buyer all stay where they are.
cost of getting it wrongtwo sources drift apart silently, and the buyer notices first
The temptation to keep your own copy of the catalogue is strong: it is faster and you do not depend on someone else's database. The copy is also the first thing to drift, and it does so unnoticed.
There is no copy. The answer is assembled from the same catalogue the shop edits by hand, so a changed price shows up in the very next answer, not after an export.
Need your correspondence to rest on your own data?
We will build it so the answer is constructed from your catalogue and a person can step in at any moment. We show a working prototype before you pay.
Discuss your task