We wire the store, the marketplaces, the payments, the warehouse and the invoicing into one operation, and put artificial intelligence on top of it with access to the real numbers. We do it every day on brands that are ours.
An ecommerce brand is split across the store, the marketplaces, the payment providers, the warehouse, support and advertising. Each piece performs its function well; none of them resolves the coordination between them, and the business pays for that. Each of these four has its own chapter below.
We met these limits in our own operation first, and the answer was not to add another tool: it was to build the piece missing between the ones we already had. That is exactly what we do today for other brands.
Today every order goes through your hands, and your team sets the ceiling.
The daily grindOnce the operation is integrated the order moves on its own until it genuinely needs a person. This is the whole path of a sale: the marked steps happen without anyone triggering them.
The order lands in one shared inbox whichever channel it came from, with marketplace packs grouped into a single unit of work.
Payment status is checked across the platform, the payment provider and the internal record, so the inbox always shows the real state.
The sale draws down the internal catalogue exactly once, and the corrected figure is published back out to every other channel.
The queue groups what has to be gathered, by product or by warehouse route, and flags before you set off if stock is short or an item has no location.
Every item is scanned against the order before it counts as packed, and fulfilment fires on its own in the originating platform.
The courier is resolved from the shipping method the customer chose, and the waybill is issued with its label and its tracking. If the customer collects, the pickup label prints instead.
The electronic tax document is issued from the same order, once, with its links to the document and to the official verification.
The customer gets the notice, the payment is reconciled, and the sale is already in the channel margin, in the report and in the context the assistant reads.
Of the eight steps, four need nobody at all and the other four resolve in one click. The only thing that genuinely takes hands is the physical part: gathering the order and dispatching it. Those four clicks could run on their own too — the confirmation is there by decision, not by limit.
Today stock stops matching, and you find out once you have sold something that was not there.
Selling what you actually haveThe most common source of loss in a multichannel operation is that every platform keeps its own record. We reverse the direction: the internal catalogue rules, and the corrected figure travels out to every channel on its own.
One SKU, one stock figure, one cost. Everything else is a publication of that.
Online store
Receives the real figure from the catalogue.
Marketplace
Receives the figure with the safety buffer applied.
The sale happens on one channel, draws down the catalogue, and the corrected figure returns to every channel. There is no second subtraction waiting.
A threshold rule publishes slightly less than there is. It exists globally and per product, and it is why the published figure sometimes differs from the real one.
No SKU, duplicated, published on one channel only, or drifted from the expected value: each case is classified and corrected with an adjustment, not with a spreadsheet.
From the last thirty days of sales, the lead time and the target coverage, the system proposes what to reorder before it runs out.
Today the real margin shows up at the end of the month, and the decisions were made before that.
Knowing where you standAsking what you sold, what needs reordering, or where the money is going should not cost half a morning of spreadsheets. The answer comes from the operation’s real data, with the same permissions as whoever is asking, and never from an invented figure.
A live picture of the business, rebuilt on every query. Every figure travels labelled with its window, its source, its unit and its definition, and anything that may be incomplete declares itself. It never contains personal data or credentials.
Thirty-six that read and forty-three that act. The assistant decides on its own whether the answer is in the database, in a live integration or in the context, and queries whatever it needs before it replies.
No action runs on the first call: it returns a preview of what it is about to do and only proceeds once that is confirmed. A tax document or a paid waybill does not get issued by accident.
The real names of the functions the assistant can call. This is not a capability list written for a landing page: it is what the code declares.
Reads36
Actions43
If it cannot confirm a figure, it says so.
The assistant’s own tools are published outward over the MCP protocol. An AI client takes an instruction in plain language and operates the business with it: no application to open, no second interface to learn. The interface is the conversation.
Works with
Ask
Act
The owner checks the business from a phone while walking, and dispatches whatever needs dispatching without sitting down in front of a screen.
Access is tied to a person and a business, and runs with the role that person holds inside it. It is not a master key, and it is revoked whenever it needs to be.
It is the assistant’s own set of functions, published outward. There is no second implementation to drift out of step, and nothing that exists on only one side.
Every action returns a preview of what it is about to do first. A tax document or a paid label is not issued in one go from a misread sentence. That is a policy, not a limit.
What is operated by conversation from a phone today is exactly what an external system can operate, with the same control and the same record. The whole operation could be left in the hands of a model with nobody watching; that somebody is always watching is our decision.
Today every new channel adds work instead of removing it.
Growing without hiringEach platform performs its own function well; what none of them resolves is the coordination between them. With that layer in place a price is defined once, a sale draws down once, and one more channel is a connection — not another system to tend by hand.
Seventeen services connected, across seven fronts
Orders from every channel land in one inbox, with their states reconciled.
The payment layer is matched against sales; nothing is ever counted twice.
One order, one document, with a test environment before anything is issued for real. It connects to whichever provider a country requires; the flow does not change.
The courier is resolved by rule from the shipping method the customer chose. Three services run today; the same pattern connects any courier with an API.
Traffic and demand are read next to sales, not in another tool.
Comments, messages and email arrive in one place and are answered from there.
Wired to real operating data, never to a sample set. Access is the same as the person asking.
Seventeen connections in production today. The list names the vendor where the name means something anywhere, and names the capability where the vendor changes by country.
These are not modules sold separately. They are the areas of a complete operation, resolved over the same data.
Omnichannel sales
Store and marketplaces, unified in one inbox.
Inventory that rules
One catalogue is the truth, and it propagates itself.
Payments and finance
The real picture of the money, not just the sales.
Invoicing and shipping
From the order to the document and the waybill, without changing screen.
Marketing and content
Social, traffic and brand — measured and actionable.
AI assistant
Ask anything about the business — and it acts, too.
Objectives and planning
Targets that measure themselves, and work that stays organised.
Multi-brand and mobile
Built for several brands at once, and to be used standing up.
17
external services connected
79
assistant tools
88
operating screens
70
data models
Figures counted from the code in production.
Melsho did not come out of a manual or a market study. Running ecommerce of our own is a business unit, with its own revenue and its own risk, and that is where all of it comes from: holding up a real operation, with its mistakes and its cost, and turning every lesson into system. Each brand keeps its own name, its own catalogue and its own relationship with its customers; what they share is the operation beneath them.
Our own risk
Every decision we make is paid for first by our own operation, warehouse included: we do not delegate logistics, we run it. That sets the standard we work to, and it sets it higher than any agreement would.
Built for several brands
The separation between businesses is structural rather than a setting: each one with its own data, its own connected accounts and its own team. Adding a brand means starting an operation, not standing up another company.
A long horizon
We build to hold, not to demonstrate. A system that has to be rebuilt within a year did not solve the problem — it postponed it.
One operation
Every new operation starts where the last one left off.
Isolation per business
Each brand lives in its own database schema. The separation is structural: there is no filter for anyone to forget.
Credentials per business, encrypted
Each operation connects its own accounts. There is no fallback credential: a business that is not connected stays not connected, and never inherits another’s.
A job queue
Slow work runs in the background with retries, and whatever fails stays visible and can be reprocessed from the panel.
Instant reads
Reads are served immediately and refreshed behind, with the cache partitioned per business so no response ever crosses from one brand to another.
Everything described on this page is running right now. There are no promised features and no concept screens.
All three are ordered by one thing only: how much of what is already built comes into your case. Nobody starts at zero, and none of the three is a subscription to a shared service.
Your stack stays yours. You change no system.
Your platforms stay where they are, and what we build is what is missing between them: the connections, the automations and the pieces somebody resolves by hand today.
Everything on this page, on an instance of your own.
If what is already built is enough for you, an instance of your own is deployed with your data, your credentials and your configuration. What gets started is a configuration, not a project.
The whole base, plus whatever your operation needs on top.
The most frequent case: nearly all of it fits, but your operation has something we do not do yet. Then nothing starts at zero — we start from a system that already works and build only the difference.
A thirty to forty-five minute call looking at how you work today: what gets resolved by hand, which systems do not talk to each other, and where your time goes. You leave with a map of what to automate first and in what order, whether you hire us or not.
Or write to us directly at [email protected]
