Each order is entered once, from WhatsApp, a salesperson or the web, and preparation, stock and the invoice come out of it. Built around how you sell today.
The order arrives on WhatsApp, by email or on paper. Someone types it into Excel. The warehouse does not know what to pick until they are told, and the invoice is issued somewhere else, with the same data again. Along the way a case goes missing, an old price gets charged or stock is promised that is not there. An order management system joins that chain. We build it around how you sell today, and we can start with the stretch that eats the most time.
You choose the modules. We start with the one that hurts most, usually order entry or stock, and the rest comes in once that stretch is in use. What follows can be included, and each module is chosen separately.
An order can come in on WhatsApp, from a salesperson on the road, at the counter or through a web portal, and it stays the same order: customer, products and the price that customer gets. If taking orders on WhatsApp ends in a chat someone copies into a spreadsheet, that order can be left entered without the second pass. Entry from the phone, for the salesperson on the road, can be defined in the scope.
Each customer can have their own list: wholesale, retail or a channel of their own, with a minimum order and a different price for a case or a single unit. When the order is entered, the price comes from that list. If the lists live in Excel, importing them can be included so nobody retypes them.
Each order moves through a status: received, being prepared, ready and delivered. Sales sees what came in, the warehouse sees what to pick and admin sees what still needs an invoice or a payment. Tracking shows where each one stands, and profiles are set by area.
On confirmation, that stock is reserved and stops being available for the next order. If you have more than one warehouse, stock can be kept separate and the order draws from the one that applies. Reorder alerts fire before the shortage reaches the customer. Orders and stock end up in one place.
Each customer has a balance: what they ordered, what was invoiced and what they paid. A payment can be recorded on the road or when it comes in through Mercado Pago, and it is assigned to that customer.
In a factory that makes to order, confirming can open a production order with the promised date. For a factory, this piece starts from that production order.
Presales on the phone, route sheets, a portal where the customer builds their own order, and importing price lists from Excel can also be looked at for the scope. What goes in is written in the scope.
What already works stays, and the system connects to it. Each piece, and the moment the data has to move, is in integrations.
The invoice can be issued when the order is confirmed or when it is handed over. Invoicing uses the customer, the items and the price already on the order. You set the moment and the receipt type.
A payment that comes in through Mercado Pago can be assigned to the order and to the customer's account. Reconciliation stops being a match of a statement against a spreadsheet.
A bot can take the order in the chat, on that customer's list, and leave it entered. If the conversation needs a person, it hands the chat over. The bot is built in AI bots. The order system receives the result.
Online sales can live on Tiendanube, on another platform or on a portal of your own. Tiendanube is one option when you already sell there or when its checkout is enough: building that store is in Tiendanube development. If the price, the minimum or the assortment does not fit a packaged store, a portal of your own can be included as a website or catalog, tied to the same order.
It fits when the order is the center of the day and today it falls apart between the chat, the spreadsheet and the program where you invoice. It is shaped by who sells and how the goods leave.
The salesperson writes the order down and at night someone types it in. The warehouse picks late and the truck leaves with whatever was ready. An order system for a distributor can leave the order entered on the visit, with that customer's list. If you run a route every day, as a food or beverage distributor does, it can be built around that route.
The counter sells at one price and the web at another, and stock finds out late. A system for wholesalers joins both channels, each with its own list. Counter and route use the same order, and the invoice can be issued when the order is picked up or when it is dispatched.
There is a promised date and what has to be made to meet it. Confirming the order can open the production order. Tracking shows whether that date still holds.
This path is an example circuit, so the pieces can be seen in order. Yours is written in the scope, based on how you work today.
The order comes in through the channel you use and lands with the customer, the products and the price from their list. If something is missing or the minimum is not met, that shows before it goes to be picked.
The warehouse sees what to pick. On confirmation, stock for those items is reserved. If there is not enough, the order shows it before promising a delivery date.
When the goods leave, or on confirmation if you set it that way, the ARCA invoice is issued with the order data.
The payment is recorded against that order and the customer's balance updates. What is still unpaid stays visible, without rebuilding it at month end.
A packaged system for distributors is enough when your circuit fits what that program already does and the team can work that way, without a spreadsheet beside it. Custom is the better fit when the path is your own: several programs plus Excel, price, warehouse or route rules that cannot be configured, or when it has to connect to what you already have.
On the first call we tell you which of the two looks like the better fit. We do not publish a price: it depends on the modules, the permissions and the connections. How that number is worked out is in what a custom management system costs. If the order is one part of a larger operation, the wider frame is management systems.
If you want to see a system that is built and in production, the EventOps case is our own product for event companies: each event is entered once, and the calendar, the quote and the payments come out of it. It shows how we build from each company's real operation.
What gets entered, who enters it, where the order comes in and where it gets stuck. That tells us where to start.
Which modules are in, what stays out, what it connects to, what it costs and when it will be ready. All clear before we start.
If the system is large, we split it and start with what hurts most, such as order entry or stock. Every week you see a working piece and try it with your team.
We roll it out with the people who enter orders, pick them and invoice them, and we adjust it from real use.
Price and timeline
They depend on how many parts the system has and what it needs to connect to. If you already pay for hosting or other services, we use them. If not, we handle them and charge their cost plus a management fee.
That can be included. A bot takes the order in the chat, with that customer's list, and leaves it entered. If the conversation leaves what the bot knows, it hands the chat to a person. If typing it in from the message is enough today, it can stay that way and the bot can be added later. It is defined in the scope.
Warranty
If a bug turns up on our side, we fix it under warranty.
Maintenance
Optional, for changes and improvements after launch. Without it, the project costs less.
Your data
It's confidential and we only use it for your project.
Tell us how an order comes in today and where it gets typed again. We reply with scope and price in writing.
Tell us your problem