You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
86 lines
4.9 KiB
Markdown
86 lines
4.9 KiB
Markdown
# 00 — Vision & Positioning
|
|
|
|
## The one-line vision
|
|
|
|
**The fastest counter in India, with a back office that runs itself.**
|
|
|
|
Every design decision gets tested against two questions:
|
|
1. Does this make billing at the counter faster or slower?
|
|
2. Does this reduce the daily data-entry burden on the shop, or add to it?
|
|
|
|
## Where we are today (SiMS Classic)
|
|
|
|
- Oracle Forms & Reports, fully offline, client-server on the shop's own machine.
|
|
- Proven domain coverage: inventory, billing, accounting, GST — customers pay for it today.
|
|
- Problems: aging tech nobody can hire for, accumulated bugs, no multi-store story,
|
|
no remote visibility for owners, every support issue needs someone at the machine,
|
|
purchase entry is manual and slow, and the market is shifting to connected software.
|
|
|
|
## What carries over (non-negotiable)
|
|
|
|
These are the things existing customers would riot over if lost:
|
|
|
|
1. **Counter speed.** Oracle Forms was keyboard-driven and instant. The new POS must be
|
|
keyboard-first and *feel* faster than Classic, not just look prettier.
|
|
2. **Works with no internet.** Billing can never stop because the connection dropped.
|
|
3. **Full GST compliance** — invoices, returns data, e-Invoice, e-Way bill.
|
|
4. **Depth of the domain model** — batches, expiry, MRP, multi-unit packs, schemes,
|
|
party ledgers, credit (khata) — everything Classic already handles.
|
|
5. **Their data.** Every existing customer migrates with full history via a Classic importer.
|
|
|
|
## What changes (the upgrade)
|
|
|
|
| Classic | Next |
|
|
|---------|------|
|
|
| Offline only, data trapped in the shop | Offline-first with cloud sync — bill offline, see everything online |
|
|
| Manual purchase entry, item by item | **Purchase Inbox**: supplier bills arrive by email/WhatsApp/upload, AI parses them, staff just confirms |
|
|
| Single store, single machine mindset | Multi-store, multi-counter, head-office console |
|
|
| Owner must be in the shop to know anything | Owner mobile app: live sales, stock alerts, approvals from anywhere |
|
|
| Support = remote desktop into the shop | Central telemetry, remote diagnostics, silent auto-updates |
|
|
| Piracy/licensing enforced awkwardly | Subscription tied to cloud account, editions unlocked by plan |
|
|
| Paper receipts only | WhatsApp e-bills, UPI dynamic QR at counter, loyalty |
|
|
|
|
## Segments & editions — one codebase, four plans
|
|
|
|
Do **not** build separate products per store size. Build one codebase with feature flags;
|
|
the plan unlocks features. This keeps mini stores cheap to serve and gives them a natural
|
|
upgrade path as they grow — which is exactly the "serve them better as they get bigger" goal.
|
|
|
|
| Edition | Target | Shape |
|
|
|---------|--------|-------|
|
|
| **Lite** | Mini/small shops, single counter | POS + inventory + GST invoices + khata + WhatsApp bills. Dead simple. |
|
|
| **Standard** | Medium stores | + multi-counter, multi-user roles, schemes/offers, barcode label printing, full purchase cycle |
|
|
| **Pro** | Large stores & supermarkets | + weighing scale integration, batch/expiry at scale, loyalty, accounting module, e-Invoice/e-Way, Purchase Inbox |
|
|
| **Enterprise** | Supermarket chains, multi-outlet | + head-office console, central pricing, inter-store transfers, consolidated GST & reporting, API access |
|
|
|
|
## Business model
|
|
|
|
- **Subscription, priced per store + per additional counter**, billed annually
|
|
(Indian retail strongly prefers yearly; offer monthly only on Lite).
|
|
- **In-app upgrades**: hitting a locked feature shows what it does and upgrades in place —
|
|
the paywall is a demo, not a wall.
|
|
- **Dealer/partner channel**: Indian retail software sells through local dealers who install,
|
|
train, and support (the Tally/Marg model). Plan dealer margins, a dealer portal, and
|
|
white-label invoicing for partners from the start — this is a distribution decision,
|
|
not an afterthought.
|
|
- **Migration offer**: existing Classic customers get assisted migration + a loyalty price.
|
|
They are the beachhead — reference customers for everyone else.
|
|
|
|
## Differentiators to lead with
|
|
|
|
1. **Purchase Inbox (AI)** — forward the supplier's bill, confirm, done. Nobody in the
|
|
Indian SMB segment does this well yet. This is the demo moment.
|
|
2. **Counter speed** — publish the numbers: scan-to-line < 150 ms, bill closed in one key.
|
|
3. **True offline-first** — competitors are either offline-only (like Classic) or
|
|
cloud-first-with-excuses. Being genuinely both is the moat.
|
|
4. **Owner app** — live business in the owner's pocket, in their language.
|
|
5. **WhatsApp-native** — e-bills, payment reminders for khata credit, offer broadcasts.
|
|
|
|
## Success metrics
|
|
|
|
- Time per billed item at counter (target: ≤ Classic, measured, not vibes)
|
|
- % of purchase lines entered via Purchase Inbox vs manually (target: 70%+ by Phase 3)
|
|
- Classic → Next migration rate (target: 80% of active base in year 1)
|
|
- Sync health: % of stores fully synced within 5 min of connectivity (target: 99%)
|
|
- Support tickets per store per month (target: half of Classic's rate)
|