Features
Tripzygo OMS is built around six capabilities. Each one replaces work that is otherwise done by hand, in separate seller panels, or in spreadsheets that go stale by the end of the week. This page describes what each capability does, what it requires from you, and where its limits are.
Nothing on this page depends on a feature we have not built. Where a workflow varies by marketplace, that is stated, because the marketplace API is what determines it.
Every connected marketplace pushes its orders into a single queue. Because each marketplace names its order states differently, Tripzygo OMS maps them onto one internal status model — new, confirmed, picked, packed, manifested, shipped, delivered, cancelled, returned — so a packer does not need to know which channel an order came from to know what to do next.
Orders are polled and, where the marketplace supports notifications, received as events, so the inbox reflects new orders within seconds to a few minutes depending on the channel. Filters cover channel, SKU, courier, payment mode, dispatch deadline, order age and fulfilment location. Saved views let each team member open straight into their own slice of work, such as “prepaid orders due today from the Ahmedabad warehouse”.
Status changes made in Tripzygo OMS are written back to the originating marketplace using its API, so the seller panel and the OMS do not drift apart. Where a marketplace does not permit a particular status transition through its API, the action is disabled rather than shown as available and failing later.
Tripzygo OMS does not create listings or change prices on marketplaces, and does not contact buyers on your behalf.
Overselling happens when the same unit is available on four channels at once. Tripzygo OMS keeps one stock pool per internal SKU. When an order is received on any channel, the unit is reserved immediately and the revised availability is pushed to every other channel mapped to that SKU.
You control how much of a SKU each channel may see. A buffer can be held back per channel or globally, so a fast-moving SKU does not go to zero on your highest-margin channel first. Multiple warehouses are supported, with allocation rules that pick a fulfilment location based on stock on hand and the delivery pincode.
Stock movements are recorded as a ledger rather than overwritten. Every change — sale, reservation release, return restock, manual adjustment, stock transfer — is a dated entry with a reason and a user, so a discrepancy can be traced instead of guessed at.
Updates are sent as soon as a movement is recorded. How quickly they take effect on a listing depends on each marketplace’s own processing of inventory updates, which is outside our control. Sync attempts, responses and failures are logged per channel so you can see exactly what was sent and when.
Dispatch is where per-order clicking costs the most time. Select a batch of packed orders and Tripzygo OMS produces the shipping labels for each one and the consolidated courier manifest for the batch in a single action, ready to print on a thermal or A4 printer.
Labels are generated through the marketplace or courier integration that owns the shipment, so the barcode, AWB and routing information are the ones the courier expects. Packing slips and, where required, tax invoices can be printed in the same run. Batches can be organised by channel, courier, pickup slot or warehouse, which matches how pickups actually happen.
Once a manifest is closed, its orders move to a manifested state and the AWB numbers are recorded against them. If a label cannot be generated for an order in the batch, that order is reported with the reason and left out of the manifest rather than breaking the whole run.
Two different things arrive back at your warehouse: customer returns, where the buyer sent the item back, and RTO shipments, where delivery never happened. Both cost money, and both are usually tracked badly. Tripzygo OMS tracks each one as a case linked to its original order, from the moment the marketplace reports it to the moment the unit is put away.
On receipt, the return is checked in against the expected item. The quality-check outcome is recorded — sellable, repackable, damaged or wrong item received — and drives what happens next: sellable units are restocked and immediately reflected in channel availability, while damaged units are held aside and do not re-enter the pool.
Because every case carries its channel, SKU, courier, return reason and outcome, the reporting shows where returns concentrate. That is what makes an RTO problem actionable: a single SKU with a high return rate on one channel is a listing or sizing issue, while high RTO across a courier and region is a delivery issue.
Where a return is lost in transit or arrives damaged, the case record gives you the dated evidence needed to raise a claim with the marketplace. Tripzygo OMS does not file claims on your behalf.
A marketplace payout is a net figure. Between the order value and the money in your bank sit commission, closing fees, shipping charges, return shipping, weight-discrepancy adjustments, promotion costs and tax. Most sellers never check the arithmetic, because doing it by hand across four channels is not realistic.
Tripzygo OMS imports each channel’s settlement report and matches every line to the order it belongs to. Deductions are itemised per order and compared against the expected fee for that order, so you see not only what was paid but what was taken and whether the amount looks right.
Discrepancies are flagged into a work queue: orders delivered but never settled, orders settled short of the expected amount, deductions charged twice, return-shipping charges on orders that were never returned, and payouts received without a matching order. Each flagged item keeps the source report reference and the order reference, which is what a marketplace support ticket asks for.
Tripzygo OMS is not accounting software and does not file returns. It produces reconciled, order-level figures that your accountant or accounting system can consume.
Every marketplace sets its own dispatch window, and a breach costs more than a late parcel: it affects account health, search visibility and in some cases penalties. Tripzygo OMS records the dispatch deadline supplied for each order and runs a clock against it.
Orders are ordered by remaining time rather than by date received, so the queue itself tells your team what to pack first. Alert thresholds are configurable — for example a warning at four hours remaining and an escalation at one hour — and can be delivered in-app or by email to the people responsible.
Non-working hours, weekly offs and holidays are taken into account so an order due on Monday morning surfaces on Saturday, not on Monday when it is already too late. Breaches, when they do happen, are recorded with the reason so the pattern is visible: a stock-out, a courier pickup that did not arrive, or simply volume the shift could not absorb.
A few things apply everywhere in Tripzygo OMS, because they are what make the system usable by a team rather than by one person.
Owners, operations staff, warehouse packers and accounts users each get access to the modules and data their role needs. Buyer contact details are visible only to roles that require them for fulfilment.
Actions that change order, inventory, return or settlement records are logged with the user, timestamp and previous value. Logs are readable by account owners and retained for review.
Sales, dispatch performance, return rates and settlement summaries can be filtered by channel, SKU and date range, then exported as CSV or Excel. Nothing is locked inside the dashboard.
Every marketplace API call the system makes on your behalf is logged with its outcome. When a channel rejects an update, you can see the request, the response and the retry, rather than a silent failure.
Most sellers start with the order inbox and inventory sync, then add reconciliation once volume makes deductions worth chasing. Tell us where the pain is and we will show you that part.