The Supply Chain Operating System · Indian Commerce

Every promise your operation makes is a slot.

A 06:00 dock door. An 18:40 carrier cut-off. A two-hour delivery window. A settlement due on the 12th. One governed system keeps them all — order to warehouse to road to register to rupee.

Built for a new kind of Indian enterprise
Quick CommerceD2C BrandsMarketplace SellersOmnichannel Retail3PLB2B Distribution

Slotwise is an India-based technology company building an AI-native Supply Chain Operating System for high-volume commerce. Slotwise is self-funded. About Slotwise

A day in the operation

Solutions

One platform. Six suites. No integration project between them.

Maturity is stated, not implied. We will not demo what is not designed.

Going live first · OMS · Returns

Capture every channel, promise what you can keep, orchestrate fulfilment, close the loop on returns.

  • Promising & slot capacity as governed commitments
  • Network sourcing across FCs, dark stores, 3PL nodes
  • Exception cockpit with rules you can backtest
  • Returns intake → grading → disposition
Explore Slotwise Order
In build · WMS · Inventory

Gate to gate-out on a scan-first floor, with hard rules at the point of scan and a ledger that reconciles itself.

  • Dock slots, ASN, GRN with batch & expiry
  • Directed putaway, waves against cut-offs
  • Three RF pick modes, pack with weight check
  • Cycle count, replenishment, kitting, offline replay
Explore Slotwise Fulfil
In build · TMS · Last mile

Serviceability to proof of delivery — NDR, RTO and cash custody as first-class workflows, not spreadsheets.

  • Carrier selection, rate cards, UNKNOWN-safe booking
  • Driver app with OTP / photo / signature POD
  • NDR workbench with priced RTO decisions
  • COD custody rider → hub → bank
Explore Slotwise Move
Reserved · POS · Marketplace

Stores and marketplaces on the same ledger as the warehouse — an oversell can’t cost you the listing.

  • Register with UPI split tender and GST e-invoice
  • Till & shift close by denomination
  • Offline-first stores with duplicate-safe replay
  • Marketplace listings, settlements, disputes
Explore Slotwise Sell
In build · Reconciliation · Finance

Settlement against operational truth — every source, every deduction, every recovered rupee traced.

  • Bank, gateway, marketplace, COD, POS ingestion
  • Matching workbench with tolerances and claims
  • e-Invoice/IRN, three-way match, TDS
  • GSTR-2B / GSTR-1 reconciliation, period close
Explore Slotwise Settle
In build · Demand & supply

Forecasts a planner can defend; recommendations that land as governed commands — not another spreadsheet.

  • Explainable forecast cells with override history
  • Scenario compare — service versus stock
  • Inventory policy with simulated impact
  • Replenishment accepted line-by-line into commands
Explore Slotwise Plan

Why Slotwise

One system, compared with the ways this is usually done.

Point tools, stitchedSuites built by acquisitionSlotwise — one system
Data modelCopies synced between toolsMultiple models, bridgedOne model, one append-only ledger
Integration projectsEvery pair, foreverBetween acquired modulesNone between suites
Exception ownershipFalls between systemsVaries by moduleOwner, age and SLA clock — built in
Audit trailPer tool, partialPer moduleOne trail, order to rupee
AI & agentsBolted on topAssistants per moduleGoverned agents at the command boundary
AdoptionRip and replaceBig-bang migrationParallel run — reversible until cutover

Platform & AI · Slotwise Govern

Correct by construction. Autonomy under governance.

One way in

The command boundary

Every state change — human or agent — enters typed, tenant-scoped, idempotent, audited.

Zero

Hand repairs

State, audit and event commit together or not at all. Failure becomes a governed UNKNOWN.

10–20M

Transactions a day

The design horizon — headroom in transactions, not orders. Sale day runs at 6× Tuesday.

66 seats

Every exception owned

Role-scoped queues with owner, age and SLA clocks; claim and escalate built in. Nothing waits in a group chat.

Agents are named principals under the same policies as everyone else. They begin by suggesting, earn approval-gated action by passing evaluation, and reach autonomy only inside limits you set — with step-back on performance drops and a kill switch per agent and platform-wide.

Agents propose and tune. Typed commands execute. Autonomy is the last thing you turn on.

Explore the platform   See the architecture

AI agents · From copilot to operator

A human always in the loop.

An illustrative example — representative data, not a logged event.

01Signal

1,840 shipments risk missing SLA this week, per carrier performance and NDR history.

02Recommendation

Move 1,120 shipments to Carrier B, per the policy version that triggered it.

03Impact estimate

Cost, avoided loss and SLA gain — a calculated estimate, not a guarantee.

04Approval

A human approves or rejects; the triggering threshold is shown alongside it.

05Execution & audit

Only the approved action executes. Every step is logged: who, what, when, why.

See how the agent layer works

The numbers we answer for

Run the operation on numbers you can defend.

No customer logos yet — instead, the measures the system is built to own, tied to the exact commands that moved the stock.

Cut-off adherenceOrder · Fulfil
Dock-to-stock timeFulfil
Pick & pack accuracyFulfil
Inventory record accuracyFulfil
Promise kept · OTIFOrder · Move
NDR & RTO rateMove
COD ageing to bankMove · Settle
Settlement match rateSettle
Leakage recoveredSettle
MAPE by lagPlan

Adoption · Reversible until cutover

You don’t have to switch to find out.

Migration and parallel run are product surfaces — coverage review, master-data mapping, dry-runs, daily parity, cutover readiness, recovery runbook.

01Connect

Slotwise reads the same order flow. Nothing is cut over.

02Run in parallel

Both systems process the same orders; only one talks to your channels.

03Reconcile daily

Counts, statuses, stock — every difference explained.

04Cut over one channel

After as many clean days as you require. You set the bar.

05Then the next

Never everything at once. Never before the evidence.

See the full methodology   Read the parallel-run playbook

Built for Indian commerce

COD reconciliationIn build
NDR managementIn build
RTO workflowsIn build
GST / e-invoicingIn build
Marketplace opsIn build
3PL coordinationIn build

Where Slotwise is today

Now

Order live first — founding cohort onboarding in waves.

Next

Fulfil, Move, Settle, Plan, and every India-commerce workflow above — in build.

Later

Sell — designed, reserved until build starts.

Book a Working Session

See it before you believe it.

A demo is a working session, not a slide deck: a pilot environment, a guided product tour, and an honest conversation about fit.

Founding cohort. A small number of brands for the first parallel runs — priority on quick commerce, marketplace-heavy D2C, and multi-facility retail.

What happens after you reach out

  • A reply within one business day from an engineer, not a queue.
  • A 45-minute working session mapped to your facilities and channels.
  • A line-by-line coverage matrix if you share a requirement list.
Book a Working Session   Email hello@slotwise.co.in
Home › Solutions

Solutions

Six suites. One command boundary. Zero integration projects.

Each suite is a commercial surface on one system — same ledger, same policies, same evidence. Pick the surface you need first; the rest are already connected.

Going live first · OMS · Returns · 26 screens

Order management, promising & slots, network sourcing, exceptions, returns and reverse logistics.

  • Omnichannel capture with governed bulk import
  • Promising & slot capacity as commitments
  • Rules with simulation and backtest
  • Returns intake → grading → disposition
  • Refund and replacement approvals
Explore Slotwise Order
In build · WMS · Inventory · 39 screens

Warehouse execution and inventory control on a scan-first floor, with 3PL operator portals.

  • Dock appointment slots and gate control
  • ASN, GRN with batch / MRP / expiry, QC holds
  • Directed putaway, waves, three RF pick modes
  • Pack with weight check, manifest, gate-out
  • Cycle count, replenishment, kitting, STOs
Explore Slotwise Fulfil
In build · TMS · Last mile · 25 screens

Transport management from serviceability to proof of delivery, with COD custody and NDR handled as workflows.

  • Carrier selection and versioned rate cards
  • UNKNOWN-safe booking and trip planning
  • Driver app with OTP / photo / signature POD
  • NDR workbench with priced RTO decisions
  • Carrier invoice audit and scorecards
Explore Slotwise Move
Reserved · POS · Marketplace · 15 screens

Point of sale, store operations and marketplace seller operations on the warehouse ledger.

  • Register with split tender, UPI, GST e-invoice
  • Returns at register with override trails
  • Till & shift close by denomination
  • BOPIS and ship-from-store on real store ATP
  • Listings, settlements, commission audit
Explore Slotwise Sell
In build · Reconciliation · Finance · 33 screens

Payment reconciliation and finance operations against operational truth, GST-native.

  • Bank, gateway, marketplace, COD, POS ingestion
  • Matching workbench with tolerances and claims
  • e-Invoice / IRN, three-way match, TDS
  • GSTR-2B and GSTR-1 reconciliation
  • Period close with sign-offs, leakage recovery
Explore Slotwise Settle
In build · Demand & supply · 16 screens

Demand sensing, explainable forecasting, inventory policy and S&OP that execute through governed commands.

  • Explainable forecast cells with driver history
  • Statistical / consensus / final layers
  • Scenario compare — service versus stock
  • Safety stock, ROP, MOQ with simulated impact
  • Replenishment into owner commands
Explore Slotwise Plan

How to read the labels

Designed. In build. Reserved.

Every suite carries one of three labels, and we will not demo what is not designed. Going live first means it ships in the first rollout wave with the founding cohort. In build means the surface is fully designed and engineering is delivering it at depth. Reserved means the design is complete but we have deliberately not started build — it will not be sold until it is.

Read where we are

Home › Solutions › Slotwise Order

Slotwise Order · Going live first

Promise what you can keep. Then keep it.

Omnichannel order management, promising and slot capacity, network sourcing, exception handling and returns — the suite that leads the first rollout wave.

What it covers

Capture, promise, orchestrate, close the loop.

  • Omnichannel capture — API, order desk, governed bulk import with row-level fix
  • Channel ingestion and validation queues with field-level reasons
  • Promising & slot capacity — delivery windows as governed commitments
  • Network sourcing across FCs, dark stores and 3PL nodes, consequences shown before the decision
  • B2B order desk — credit exposure, contract pricing, split and backorder proposals
  • Amendments and cancellation propagated to floor and pack in real time
  • Exception cockpit by taxonomy — address, payment, stock, fraud, promise breach
  • Order rules with simulation and backtest before activation
  • Customer resolution workspace with safe, templated communication
  • Returns intake → inspection and grading → disposition, photos and serials kept
  • Refund and replacement approvals with amount breakdown and policy basis
  • Customer return portal, reverse pickup, RTV with vendor credit notes
Wave against the cut-off · Shift lead

82 orders inside the carrier cut-off; labour and capacity previewed before release. Capacity short → affected orders are re-promised before the customer notices, not after.

Amendment mid-pick · Order desk

A customer changes the delivery address after the wave is released. The amendment propagates to the pick task and the pack station; the label is regenerated before the carton is sealed.

Home › Solutions › Slotwise Fulfil

Slotwise Fulfil · In build

Gate to gate-out, on a scan-first floor.

Warehouse management and inventory control with hard rules at the point of scan, an inventory ledger that reconciles itself, and portals scoped for 3PL operators.

What it covers

Inbound, inventory, outbound — one ledger.

  • Gate entry and vehicle register — documents, hold or reject with reason, dock allocation
  • Dock appointment slots — templates, booking, adherence, supplier self-booking
  • ASN against PO / STO; receiving with over, short and damage per line
  • GRN with batch, MRP and expiry; shelf-life thresholds enforced at receipt
  • QC sampling by SKU configuration; failed stock blocked from allocation
  • LPN and palletisation rules — mixed-pallet limits, single-SKU racking, no mixed expiry
  • Directed putaway — put-to-empty, reserve versus pick-face, alternate-bin recovery
  • Waves against carrier cut-offs with labour and capacity preview
  • Three RF pick modes — pallet, case, each — with cluster carts and totes
  • Pack station — unit verification, weight variance, multi-carton, scan-triggered video
  • Consolidation staging, manifest by carrier, load-by-scan gate-out
  • Bin-level replenishment — min/max, demand-driven and ad hoc; pallet and case RF flows
  • Cycle count with recount loop and rule-based triggers; putaway audit
  • Adjustments with value bands and maker-checker approval; lot and serial trace
  • Kitting and VAS work orders with BOM consumption and finished-goods putaway
  • Offline task journal — queued scans replay duplicate-safe when the network returns
  • Scan-first on rugged handhelds and tablets — large targets, built for the floor
  • STO lifecycle with in-transit visibility; scoped 3PL operator portal
Gate & dock window · Inbound executive

Vehicle at the gate against a booked slot; documents verified, dock assigned, detention clock running. Late arrival → the window is re-slotted with penalty evidence attached.

Short pick on the floor · Picker, handheld

Bin empty at A03-02. Reason coded on the handheld, an alternate-location task lands in the same pick cycle, and a recount is queued automatically.

Home › Solutions › Slotwise Move

Slotwise Move · In build

Serviceability to proof of delivery — with the cash accounted for.

Transport management for Indian networks, where NDR, RTO and COD custody are first-class workflows rather than spreadsheets nobody trusts.

What it covers

Book it once. Track it honestly. Close the cash.

  • Serviceability and carrier selection — pincode, TAT, cost, COD eligibility
  • Rate cards as lane × weight-slab matrices with surcharges and versioned contracts
  • Booking with UNKNOWN-safe recovery — a provider timeout never double-books
  • Load and trip planning with vehicle capacity and cut-off warnings
  • Driver app — stop list, navigation hand-off, OTP / photo / signature POD, COD collection
  • Milestone tracking with exception-first views
  • NDR workbench — reasons, contact log, reattempt slots, RTO decisioning with cost
  • COD custody trace — rider to hub to bank, remittance by partner
  • Hub shift closure with transport and finance residuals in one checklist
  • e-Way bill and LR documents; carrier invoice audit against contracted rates
  • Carrier scorecards — OTIF, NDR rate, claims; fleet readiness and document expiry
NDR on the road · NDR desk

“Customer unavailable” logged with a reattempt slot the customer chose. Third strike → the RTO decision is priced — return freight, restock, margin — before another trip is wasted.

Hub close · Hub cashier

COD counted rider by rider against the day’s deliveries. Variance → an owned exception with an approval trail, not a diary entry.

Home › Solutions › Slotwise Sell

Slotwise Sell · Reserved

Stores and marketplaces on the warehouse ledger.

Point of sale, store operations and marketplace seller operations — so an oversell can’t cost you the listing, and a till never balances against a guess. Design complete; build not yet started, and we say so.

What it will cover

Register, store, marketplace — one stock truth.

  • Store register — scan-to-cart, promotions, split tender including UPI, GST invoice and e-invoice
  • Returns and exchanges at register with manager override trails
  • Till and shift close — tender breakdown, denomination count, variance approval, deposit
  • Offline-first stores — duplicate-safe replay when connectivity returns
  • Store orders board — BOPIS and ship-from-store with pickup SLAs against real store ATP
  • Store stock with online-reservation split and one-tap replenishment requests
  • Marketplace seller onboarding, listings and identifier mapping with rejection reasons
  • Order trace per channel; settlements, payouts, commission audit, disputes
Till close · Store manager

The store till balanced by denomination against the register’s tender log. Variance → owned exception with approval trail; deposit slip generated from the count, not retyped.

Reserved means exactly that: we will not demo Slotwise Sell until it is in build. Register interest and we will tell you when that changes — and not before.
Home › Solutions › Slotwise Settle

Slotwise Settle · In build

Settlement against operational truth.

Every source, every deduction, every dispute — matched line by line to the ledger that actually shipped the box, and posted with controls. GST-native, TDS-aware, audit-ready.

What it covers

Reconcile. Recover. Close the period.

  • Source ingestion — bank, gateway, marketplace, COD partner, POS tenders — with completeness controls
  • Matching workbench — auto, suggested, unmatched; tolerances, many-to-one, fees, TDS and GST columns
  • Commission and fee compare against the commercial basis; over-charges claimed with evidence
  • COD remittance reconciliation by courier partner; gateway settlement by MID
  • Chargebacks and disputes with evidence packs — pack video, waybill, POD
  • Billing, e-invoice / IRN, AR and credit control; three-way match at line level
  • Payment proposals with due dates, discounts and TDS; bank file export
  • GST reconciliation — GSTR-2B versus purchase register, GSTR-1 versus sales, ITC eligibility
  • Revenue recognition, posting intents, period-close checklist with sign-offs
  • Leakage analytics — fees, RTO, damage, shrink — with a recovery pipeline
Settlement lands · Reconciliation analyst

The marketplace file matched line by line against shipped truth. Short by ₹11,940 → a commission over-charge claim goes out with the pack video attached.

Period close · Controller

Posting intents reviewed by source; GSTR-2B mismatches listed with vendor and invoice. Close checklist signed off with the evidence linked, not attached later.

Home › Solutions › Slotwise Plan

Slotwise Plan · In build

Forecasts a planner can defend.

Demand sensing, explainable forecasting, inventory policy and S&OP — where every cell explains itself, every override keeps its reason, and recommendations land as governed commands, not another spreadsheet.

What it covers

Sense, forecast, decide, execute.

  • Demand sensing across channels with data-quality flags
  • Explainable cells — driver contributions, override history, model lineage
  • Planner workbench with statistical, consensus and final layers and versioned edits
  • Scenario builder and compare — assumptions side by side, service versus stock trade-offs
  • Accuracy and bias — MAPE / WMAPE by hierarchy and lag, worst-offender drill-downs
  • Event and promotion calendar feeding the plan — sale day at 6× Tuesday, modelled
  • Inventory policy — safety stock, ROP, MOQ, review periods with simulated impact
  • Replenishment recommendations accepted line-by-line into owner commands
  • Network and capacity view; plan approval with supply feasibility shown
  • S&OP consensus with the audit trail of who changed what, and why
Weekly plan review · Planner

A forecast cell jumps 40% for a hero SKU. The cell shows its drivers — promotion calendar, marketplace trend, last year’s festive lift — and the override history. The planner accepts three replenishment lines into commands, defers two.

Home › Platform & AI

Platform & AI · Slotwise Govern

The substrate is the product.

Every suite shares one command boundary, one policy layer, one append-only ledger, one evidence store and one agent runtime. That is why there is no integration project between them — and why every action is attributable, reversible and auditable.

The command boundary

One way in. Every state change — whether a picker’s scan, a planner’s override, an ERP posting or an agent’s decision — enters through a typed, tenant-scoped, idempotent command. Commands carry identity, intent, scope and an idempotency key; replaying one is safe by construction, which is what makes offline floors and flaky provider APIs survivable.

Atomic truth. State, audit record and outbound event commit together, or not at all. If execution fails halfway, nothing is half-written and nothing is repaired by hand.

Failure is a state. Provider outages and unknown outcomes become governed UNKNOWN records with a safe recovery path — a courier booking that timed out is reconciled, never blindly retried into a double booking.

Policy layer and ledger

Allocation, approvals, carrier choice, credit, replenishment — all policies are versioned, owned and backtested against history before activation, and reversible after. A policy change is itself a command with a receipt.

The inventory ledger is append-only: corrections are new entries with reasons, never edits to history. Every recovered rupee, every adjusted count, every reversed allocation keeps its lineage — which is what makes settlement reconciliation tractable and audit sampling trivial.

The agent layer

ten internal test suites

Agents are named principals under the same policies as everyone else. They begin at suggest, earn approve-gated action by passing evaluation, and reach autonomy only inside limits you set — value ceilings, scopes, hours. If measured performance drops, autonomy steps back automatically. A kill switch exists per agent and platform-wide, and every agent action carries the agent’s identity into the audit record.

Agents propose and tune. Typed commands execute. Autonomy is the last thing you turn on, not the first.

A carrier-selection agent, in stages.

Representative data — not a logged production event.

  1. Signal. 1,840 shipments are flagged at risk of missing SLA this week, from carrier performance, transit-time history and current NDR rate by pin code.
  2. Recommendation. The agent proposes moving 1,120 of them to Carrier B, citing the policy version that triggered it.
  3. Impact estimate. Incremental cost, expected avoided loss and SLA improvement — shown as a calculated estimate, not a guarantee.
  4. Approval. A human approves or rejects, with the threshold that triggered the recommendation shown alongside it. Once approvals pass evaluation, routine cases inside a value ceiling you set can move to approve-gated action; anything above that ceiling always queues for review.
  5. Execution and audit. Slotwise executes only the approved action. Every step carries its identity into the audit record — who, what, when, why — and can be reversed like any other command. A kill switch, per agent or platform-wide, is always available to your administrators.

Access and evidence

Capability-level roles with segregation-of-duties checks, access-review campaigns, and just-in-time support sessions with independent approval. Evidence is captured at the moments disputes happen — scan-triggered video at pack and returns, retrievable by order — and audit workpapers are immutable.

Architecture

How the layers fit together.

One way in

Command boundary

Typed, tenant-scoped, idempotent, audited.

Zero

Hand repairs

Atomic commits; failure becomes a governed state.

10–20M

Transactions a day

Design horizon — headroom in transactions, not orders.

headroom measured in transactions, not orders

66 seats

Every exception owned

Owner, age, SLA clock; claim and escalate built in.

Integrations · No rip and replace

Fits the stack you already run.

The parallel run reads your current order flow on day one. Every interface carries a contract, a run history, and a rejected-record queue that names the failing field — corrected and reprocessed here, without asking the other system to re-send.

SurfaceInbound to SlotwiseOutbound from SlotwiseFailure handling
ERP & financePOs, STOs, kitting orders, customer and credit master, supplier lead timesGRNs, inventory movements, posting intents, three-way match resultsContract per interface; field-level rejected-record queue
Marketplaces & storefrontsOrders, cancellations, returns manifests, settlement filesInventory, listings and identifier mapping, shipment statusChannel-level completeness controls; duplicate-safe replay
Couriers & carriersMilestones, POD, NDR feeds, freight invoicesBookings, manifests, e-way bill dataUNKNOWN-safe booking; invoice audit against contracted rates
Payments & banksGateway settlements by MID, COD remittances, bank statementsPayment proposals, bank filesStatement completeness checks before matching
Compliance rails (GSP)GSTR-2B and GSTR-1 datae-Invoice / IRN, e-way bill requestsRetry with receipts; nothing filed twice

Discuss your stack   See the adoption path

Home › Industry

Industry

Built where the seams cost the most.

Indian commerce at 20,000–100,000 orders a day — and six times that on sale day. Five segments, one system, and the compliance rails underneath all of them.

Quick commerce

The window is the contract. A PO lands at 11pm; the 6am dock slot is already committed to a partner who will dispute detention. Slot-governed dock appointments, wave cut-offs and two-hour promises live in one system, with penalty evidence attached when a window is missed — by either side.

  • Dock slot templates with supplier self-booking and adherence tracking
  • Dark-store replenishment against hourly demand, not daily averages
  • Two-hour promise capacity as a governed commitment, re-promised before the customer notices

Suites: Order · Fulfil · Move

D2C & marketplaces

Margin hides in deductions. Commission audit against the commercial basis, settlement matching by line, RTO decisions priced at true cost before another trip is wasted, and claims that ship with pack video attached.

  • Fee and commission compare per marketplace, with an evidence-backed claims pipeline
  • NDR workbench with customer-chosen reattempt slots
  • COD custody traced rider → hub → bank, ageing visible to finance

Suites: Order · Move · Settle

Omnichannel retail

Store and FC, one ledger. BOPIS and ship-from-store against real store ATP, GST-compliant billing at the register, offline floors that replay safely, and shift closes that balance to the rupee by denomination.

  • Online-reservation split on store stock, so the shelf and the site agree
  • Register with UPI split tender and e-invoice where applicable
  • Till variance as an owned exception with approval trail

Suites: Sell · Fulfil · Settle

3PL & fulfilment providers

Many tenants. Hard walls. Scoped operator portals per site and client, SLA evidence by task, and billing events generated from the same commands that did the work — so a client dispute is settled by the ledger, not by a screenshot.

  • Tenant isolation enforced at the command boundary
  • Per-client SLA clocks on receiving, putaway, pick and dispatch
  • Activity-based billing from receipts, not from timesheets

Suites: Fulfil · Govern

B2B distribution

Credit before commitment. Credit exposure at the order desk, contract pricing, split and backorder proposals a rep can explain, and STOs with in-transit stock visible at both ends.

  • Contract price lists with effective dates and approval
  • Backorder proposals with promise dates from supply feasibility
  • Three-way match on the purchase side, dunning on the receivable side

Suites: Order · Fulfil · Settle

Indian compliance, native

GST e-invoice and e-way bill through GSP, GSTR-2B and GSTR-1 reconciliation, TDS on payables, COD custody — from the same ledger, not a bolt-on. Data lives in Indian regions by default.

Suites: Settle · Move · Trust center

Home › Adoption

Adoption · Reversible until cutover

You don’t have to switch to find out.

Migration and parallel run are product surfaces in Slotwise — coverage review, master-data mapping, dry-runs, daily parity, cutover readiness and a recovery runbook — not a services promise on a slide.

Five phases

Never everything at once. Never before the evidence.

01Connect

Slotwise reads the same order flow. Master data mapped, dry-run imported. Nothing is cut over.

02Run in parallel

Both systems process the same orders; only one talks to your channels. Exceptions surface here, safely.

03Reconcile daily

Counts, statuses, stock — by facility and channel. Every difference explained, every fix a governed command.

04Cut over one channel

After as many clean days as you require. You set the bar; the readiness checklist enforces it.

05Then the next

Channel by channel, facility by facility. The recovery runbook stays live until the last cutover.

What “parity” means, precisely

MeasureCompared dailyCutover gate
Order counts by channel and statusLegacy vs SlotwiseZero unexplained differences, N consecutive days
Stock on hand by facility and SKULegacy vs Slotwise ledgerVariance within your tolerance band
Promise dates and cut-off adherencePer orderSlotwise equal or better
Settlement match ratePer sourceMatch rate equal or better, breaks explained

Founding cohort

A small number of brands for the first parallel runs — priority on quick commerce, marketplace-heavy D2C and multi-facility retail. Terms are set per parallel run, scoped to facilities and channels, with success criteria agreed before we start. List pricing follows the cohort.

What the cohort gets: a named engineer, a war-room during the parallel run, severity-1 response around the clock during cutover, and direct influence over what ships in the second wave.

Questions you should be asking

Why run my operation on software from a company without reference customers?

You shouldn’t — not blind, and not all at once. Check the architecture, walk the product, then start with one facility and one channel, alongside what you already run.

What exists today?

The full surface is designed; Slotwise Order leads the first rollout wave; the remaining suites are in build or reserved, and every module is labelled. What is in development is delivery at full depth, not the design.

Six suites from a company this size sounds like a lot.

It would be, if they were six products. They are one system with six commercial surfaces — most of the work is the substrate, not the modules.

We already run something that works.

Which is why the entry path is a parallel run, not a replacement. Compare both daily; move one channel when the numbers have agreed for as many days as you require.

I’m not letting AI touch my orders.

Neither would we, on day one. Agents start by suggesting and move up only by passing evaluation, within limits you set. Every action is attributable and reversible.

Where does our data live?

Indian regions by default. Tenant-scoped commands, an append-only ledger, a complete audit trail. ISO 27001 certified.

Home › Resources

Resources

Evaluate us properly.

Everything an architecture review, security review or RFP team needs — readable here, before go-live, without a form in the way.

Home › Resources › Launch briefing

Launch briefing · Updated 1 September 2026

Going live, in waves.

What ships first, who gets it, and how the rollout is sequenced so that nothing goes live before the evidence.

Wave 1 — Slotwise Order and the platform

The first wave ships Slotwise Order on the full Slotwise Govern substrate: command boundary, policy layer, append-only ledger, evidence store, integration fabric and the agent runtime at suggest level. Founding-cohort brands run it in parallel with their current OMS, channel by channel.

Wave 2 — Execution and money

Fulfil, Move and Settle follow, in the order cohort brands need them. Each enters parallel run against the customer’s existing system with the parity gates described in the playbook. Plan ships once two quarters of Slotwise sales history exist to forecast from.

Reserved — Slotwise Sell

Sell is designed and deliberately not yet in build. It enters build when a cohort brand with stores commits to a parallel run for it. We will not demo it before then.

Calendar

MilestoneWhoStatus
Founding cohort onboardingSelected brandsOpen now
Wave 1 parallel runs beginCohortRolling, per brand
First channel cutoversCohortAfter parity gates
Wave 2 suites enter parallel runCohortSequenced by need
General availability and list pricingEveryoneAfter the cohort completes
We publish dates when they are commitments, not intentions. Ask us in a working session and we will tell you where your facilities and channels would fall in the sequence.

Join the founding cohort

Home › Resources › Parallel-run playbook

Playbook · For operations and programme leads

How a parallel run actually works.

Parity metrics, reconciliation cadence, cutover gates and rollback — the whole method, so you can hold us to it.

Before day one

  • Coverage review. Your requirement list mapped line by line — covered, partial, missing — before anything is connected.
  • Master-data mapping. SKUs, locations, BOMs, customers, carriers, price lists; dry-run imported with a rejection report you can act on.
  • Scope. One facility and one channel to start. Written down, with the success criteria.

During the run

  • Shadow processing. Slotwise processes the same orders; only the legacy system talks to channels and carriers.
  • Daily parity. Order counts by status, stock by facility and SKU, promise dates, settlement matches — compared every day, every difference explained and logged.
  • Exception drills. Short picks, late vehicles, NDRs, settlement breaks handled in Slotwise and compared against how they were handled in legacy.

Cutover gates

GateThresholdOwner
Clean parity daysN consecutive days — you set NYour programme lead
Stock varianceWithin your tolerance band by facilityYour inventory controller
Exception ownershipEvery open exception has an owner and an SLA clockYour ops lead
Recovery runbookRehearsed once end-to-endJoint

Rollback

Until cutover, rollback is switching the channel connection back. After cutover, the recovery runbook restores the legacy path within the agreed window; the ledger keeps every command issued in between, so nothing is lost or double-processed.

Plan a parallel run   Adoption overview

Home › Resources › Requirement coverage

Evaluation · How your RFP gets answered

Line by line. Honestly.

Send us your functional-requirement list or RFP. We return a coverage matrix — every line marked covered, partial or missing, with the suite, the screen and the note that explains it.

How it works

  1. You send the list — spreadsheet, document, or the RFP itself.
  2. We map each line to a suite and a capability, and mark it covered, partial or missing. No “yes with customisation” answers.
  3. You get the matrix back within five business days, with the missing lines grouped into what is in build, what is reserved, and what we will not build.
  4. We walk it with you in a working session and agree what a parallel run would prove.

What a row looks like

Your requirementStatusSuite · capabilityNote
Dock appointment scheduling with supplier self-bookingCoveredFulfil · Dock slotsTemplates, adherence tracking, penalty evidence
Rule-based cycle count triggersCoveredFulfil · Cycle countBin flags, velocity, exception-triggered recounts
Kitting with BOM consumptionPartialFulfil · Work ordersConsumption and FG putaway covered; disassembly in build
Marketplace commission auditCoveredSettle · Fee compareAgainst commercial basis; claims with evidence
Labour management and incentive payMissing—Not planned; task productivity is reported, pay is not computed
Honesty is the point. A matrix full of “yes” is worth nothing in a parallel run; a matrix with a few clear “missing” rows is a plan.

Send your requirement list   Email it directly

Home › Contact sales

Book a Working Session

See it before you believe it.

A demo is a working session, not a slide deck: a pilot environment, a guided product tour, and an honest conversation about fit. We reply within one business day.

Tell us about your operation.

Founding cohort. A small number of brands for the first parallel runs — priority on quick commerce, marketplace-heavy D2C and multi-facility retail.

Have a requirement list? Mention it in the message and we will return a line-by-line coverage matrix — covered, partial, missing.

Something went wrong sending this. Please try again, or email hello@slotwise.co.in.

Request drafted

Thanks, there.

Your request is ready. Send it from your email in one click — we reply within one business day with a working-session slot.

Send from my email   Back to home

↑ Top