Ecom Automation

Challenge

The client is a sewing manufacturer selling online: around a hundred clothing models, sales driven by social media ads, Sitniks CRM, delivery via Nova Poshta and Ukrposhta, warehouse and workshops tracked in Google Sheets. A situation familiar to almost every ecom business with in-house production:

• What to sew was decided by hand. Demand in the CRM, stock in one sheet, workshops in another tab. Understanding what was missing meant merging it all in your head.
• Material purchasing was estimated by eye. The result: either idle workshops or excess fabric rolls in the warehouse.
• Nobody reconciled cash-on-delivery money. Transfer registries arrived by email; matching them to orders manually was unrealistic.
• No one knew which models actually made money. Ads in two accounts, cost in one file, sales in another.
• Managers answered "what's the price?" by hand, including nights and weekends.

What we did

A system that delivers ready decisions every morning at 7:00, with totals in two currencies:

• Production planning. The system takes demand from the CRM, stock from the warehouse and workshops, plus goods coming back as returns, and produces the plan: which model, color, and size to sew today. Batches are rounded to production tens.
• Material purchasing and finance report. Fabric and accessories are calculated for the plan: meters roll up to fabric rolls, pieces to packs, prices to totals in dollars and hryvnias. The list lands in the purchasing chat, split by supplier.
• Cash-on-delivery control. Every shipment is reconciled against the postal transfer registries: money received, different amount received, still waiting, overdue past 10 days. Registries are pulled from the mailbox automatically.
• Returns tracking. Through the postal APIs the client sees what has physically returned to the warehouse, what is still in transit, and what is stuck at a branch. Returned goods immediately count as stock and are not sewn twice.
• Analytics and a model rating. A single efficiency score from six metrics: margin, redemption rate, conversion, cost per order, cost per dialog, sewing complexity.
• Automatic replies to buyers. The system identifies the model from the ad the dialog came from, takes the price from the product card, and answers in seconds, then hands the dialog to a manager.
• An admin panel with roles. Finance sees the money, production sees the plan, purchasing sees the materials.

Results in numbers

• Materials are calculated for 94% of the plan instead of 45%. The share of the plan the system could not price fell from 55% to 6%. For the main fabric alone, the order grew from 5 to 17 rolls - exactly what was actually needed.
• Over a quarter of a million hryvnias of cash-on-delivery under control. A control run over just two days of shipments put 307 parcels worth 272,455 UAH under watch, with a named list of those where money had not arrived.
• 24% of that money was completely invisible. Shipments via the second carrier were technically missing from reconciliation: 74 parcels out of 307, almost 73,000 UAH. Found on live data, not in tests.
• Buyers get an answer in seconds instead of 1.5-2 minutes, around the clock. The system replies only where the price is unambiguous: 108 out of 122 products.
• The model rating is built on the full sales history - tens of thousands of orders reduced to per-model metrics.

How we worked

About six weeks from the first conversation to a system running daily without a developer involved. Each block shipped separately and was useful immediately: first the calculation core (plan + purchasing), then connectors to the CRM, mail, and sheets, then analytics, and finally auto-replies and money control.

The principles that make this work:

• Verify on live data. Half of the most expensive mistakes were found by running the system on the real warehouse, not in tests.
• The system stays silent rather than lying. A zero balance often means "being sewn right now", so the buyer is never told "out of stock".
• A human edit is the source of truth. The system never overwrites what a person typed into the sheet. The client kept their Google Sheets: the system reads them as they are.
• Every number is traceable down to the sheet row it came from.

Stack: Supabase (PostgreSQL), React, Claude, Sitniks CRM API, Nova Poshta and Ukrposhta APIs, Google Sheets API, Telegram Bot API.