Sudarshan by SkySentinel Book a demo

Distributor ERP · live in Cachar, Assam

Distribution shouldn't take 40 phone calls a day.

Sudarshan is a distributor ERP running right now on a real FMCG business in southern Assam — order entry, packing, owner approvals, loading sheets, billing, and accounting handoff. No translated SAP. No generic CRM.

Retailers served 1,334
Orders processed 10,478
Active routes 23

Not demo numbers. Extracted 25 August 2026.1

Phase 01 — dispatch

ORD-2041 leaves the depot at 09:14.

ORD-2041 · price exception

Retailer
Sample Retailer A
Line
Ghee 1L · 24 units
Ask
2.5% below list
Approved by owner · 09:22

Retailers

1,334

distinct retailers on the live catalogue

Orders

10,478

orders through the workflow in 127 days

Routes

23

routes loaded from one sheet

Catalogue

1,354

products priced in one place

Orders per working day, by month

Apr–Aug 2026 · 127 days live2

April · onboarding ramp

May–August · steady operating load

From zero to full operating load in six weeks — and flat ever since. April is the onboarding ramp: 891 retailers onboarded in the first six weeks, 106 in the first eight days and 785 in the first full month. Every month after it is the system carrying the depot's real daily volume without degradation. Rupee values are not published.

Keep scrolling — the load unpacks itself

One live record

Five states. One record. No re-keying.

Distribution rarely fails at one big moment — it leaks at the seams between the people who take, approve, pack, and bill an order. Each stage below is a state on the same order, not a separate document.

  1. 01

    Capture

    Sales enters the retailer order against the live catalogue — one retailer, one price list.

  2. 02

    Approve

    Price and exception decisions reach the owner with context, not as a mid-route phone call.

  3. 03

    Pack

    The warehouse works from the current state, so an approved change is the line that gets picked.

  4. 04

    Bill

    Confirmed order data moves into billing and the accounting handoff without being re-typed.

  5. 05

    Dispatch

    Loading and departure status stay visible, so "has it left?" is answered by the record.

What actually breaks

Six specific leaks, and the mechanism that closes each.

Paper slips ride in the delivery van.

The order record moves through states in the app; the van carries a loading sheet printed from it, not the only copy.

The 6am loading sheet is already stale.

Sheets generate from current order state at print time, so an overnight approval is on the sheet the loader holds.

The owner is a 40-call-a-day bottleneck.

Price exceptions queue as approvals with the order context attached — decided in a batch, not interrupted per call.

Orders arrive by call, paper, and message.

Every order is captured against one retailer and one live catalogue, whatever channel it came in on.

Packing, billing, and dispatch disagree.

One order record moves through each operational state, so there is no second version to reconcile.

Accounts re-type what the depot already knew.

Confirmed operational data exports into the existing billing and accounting workflow instead of being keyed twice.

The bottleneck we designed against

Forty calls a day to the owner, or one queue he clears before the vans load.

Every price exception used to be a phone call that stopped whatever he was doing. Now they queue with the order context attached — and the decision lands on the record the warehouse is already working from.

Evidence, classified

Production evidence, without forecasts.

Observed values come straight from production records. Anything calculated or assumed carries its label, its source, and its extraction date.

The bottleneck, measured

Observed

13,469

Owner approval decisions routed through the queue.

Piece, price, discount, item, retailer and product requests · 127 days1

Observed

11 min

Median owner turnaround on a price exception.

Measured created-to-reviewed interval on 4,038 requests1

Derived

~106/day

Approval decisions per working day.

13,469 ÷ 127 days, no forecasting2

Sustained operation

Observed

127 days

Continuous production operation, no rollback.

20 April – 24 August 20261

Observed

98.3%

Order accuracy across the deployment.

178 of 10,478 orders invalidated (1.7%)1

Observed

64,355

Order lines processed.

6.2 lines per order on average, 112 at maximum1

Observed

24

Active users across four role types.

1 owner, 10 staff, 11 packing, 2 computer1

8,814 packing records · 7,202 accounting exports generated · 20,720 carton movements logged · 45,271 in-app notifications delivered

Order-entry benchmarks

Modeled

15 min / order

Order entry before Sudarshan.

Hand-anchored benchmark3

Modeled

3.5 min / order

Order entry with Sudarshan.

Hand-anchored benchmark3

Derived

4.3×

Order-entry throughput ratio.

15 ÷ 3.5, no forecasting3

Honest fit

Built for you if

  • You run ₹5–50 crore of FMCG turnover through your own depot.
  • 300+ retailers across multiple routes, loaded daily.
  • Your accounts already live in a standard ledger you intend to keep.
  • The owner still signs off price exceptions personally.

Not for you if

  • You want a warehouse-management or accounting replacement.
  • You need a multi-country, multi-entity rollout on day one.
  • You expect named customer testimonials before a pilot — we do not publish them without consent.
  • You need capabilities we cannot yet evidence in production.

Owner oversight

Price and exception decisions route through a visible approval step.

Shared order state

Sales, packing, billing, and dispatch stay aligned to one record.

Accounting handoff

Confirmed operational data moves into your existing billing workflow.

Privacy by design

Aggregate evidence only — no customer- or order-level data published.

For whoever vets the vendor

What the engineering has to survive.

The owner decides whether Sudarshan fits the business; someone else usually decides whether it is safe to depend on. These are the checks that run against the system that holds the depot's live data.

637 automated tests

The full suite runs in about six seconds, on every change, before anything reaches production.

Zero referential-integrity failures

31 foreign-key checks across 249,306 records return no orphans — no order pointing at a retailer that no longer exists.

Row-level security on every table

No table is open by default; the application connects through an explicit bypass role rather than an implicit one.

Per-role isolated sessions

Four separate role cookies, so one device can hold more than one role without the two bleeding into each other.

Immediate session revocation

Changing a credential closes every active session on it, rather than waiting for a token to expire.

Real-time state, with a fallback

Server-sent events push order state as it changes, and fall back to polling where the connection will not hold.

Zero-downtime schema operations

A 9.8 GB migration ran against live production with before-and-after verification proving 23 tables, 249,306 rows and 88 numeric column sums byte-identical either side.

Where this goes

One depot proven, then outward.

The system runs on one real operation today. Everything after that is sequencing, not speculation — and each step is only claimed once it is in production.

  1. Today

    Cachar, Assam

    Live in production: 1,334 retailers, 23 routes, one owner approving exceptions in a queue.

  2. Next 12 months

    Barak Valley

    Neighbouring distributors on the same route-and-approval model, one depot at a time.

  3. Then

    Upper Assam + Guwahati

    Larger catalogues and multi-depot operations, once the single-depot workflow is boring.

  4. Longer term

    Northeast, then India

    The same controlled workflow wherever FMCG distribution runs on routes and personal price calls.

Pilot path

Four controlled stages, each with an exit.

Scope is agreed before configuration begins, and every stage ends with an explicit decision on whether to continue — rollout timing stays with your operation.

  1. Stage 01

    Discovery

    Map order capture, approvals, warehouse handoffs, and billing constraints.

  2. Stage 02

    Configuration

    Define the scoped workflow, users, routes, and decision rules.

  3. Stage 03

    Controlled pilot

    Run Sudarshan with a bounded operating group and agreed measures.

  4. Stage 04

    Operational review

    Review adoption, exceptions, and rollout readiness before expansion.

Next step

See the workflow on a live operation.

A demo walks through order capture, price approval, packing, billing, and dispatch status in one session. A pilot follows only once the operational fit is clear on both sides.

Prefer a direct conversation? Email main@skysentinel.co.in, call +91 97302 65133, or contact the founder on LinkedIn.

Request a demo

Tell us about your depot and we'll come back within two working days.

Notes & method

  1. Observed. Aggregate counts extracted read-only from production records of the Cachar deployment on 25 August 2026, covering 20 April to 24 August 2026 — 127 days. No customer-level data, order IDs, or per-route revenue are published, and no rupee values.
  2. Working days. The monthly series plots orders divided by the working days in each month. August 2026 is a partial month, through 24 August. Rupee values are withheld.
  3. Modeled and derived. Order-entry minutes are hand-anchored operating benchmarks (15 before, 3.5 after); the 4.3× ratio is their quotient. Nothing on this page is projected forward.

The company behind Sudarshan

SkySentinel

Technologies Private Limited

Sudarshan is a SkySentinel Technologies product. We build operating software for businesses that run on routes, depots and personal decisions — starting in the Northeast, where the operations we design for are the ones we can stand next to. Every claim on this page comes from a system we run in production, not a pitch deck.

Registered office
Borbora NWS, 3rd Floor, Bye Lane 2, Indrapur,
Guwahati (GMC), Kamrup, Assam 781032, India
CIN
U72100AS2026PTC030972