RSV Global / Work / SolDelights Field Sales

Field sales software built for
the phone in a shopkeeper's hand.

A field sales platform for Indian retail, designed around low-end Android devices, patchy connectivity and the fact that the shop owner physically holds the agent's phone while the order is placed.

The problem

The order book lived in WhatsApp.

Orders arrived by phone call and WhatsApp message. The founders then transcribed them by hand into Zoho Books. The transcription step was where errors entered, where the day's orders stalled, and where founder time went instead of into selling.

Constraint

Devices

Low-end Android handsets, not flagship phones.

Constraint

Connectivity

Indian retail conditions, where the network drops mid-order and does not come back on cue.

Constraint

Environment

Bright sunlight, and a screen held by the shop owner rather than the agent.

Constraint

Economics

The infrastructure had to cost effectively nothing until order volume justified otherwise.

Architecture

How the system is put together.

01Offline queue. Orders are captured locally and synchronised when the network returns. The agent never waits for connectivity to take an order.
02Four-step order flow. The mobile flow is compressed to four steps, because it is completed standing up, on someone else's phone.
03Shop search and GPS visits. Visit capture with location, plus shop lookup against the existing customer list.
04Founder approval. Orders reach a founder for approval before they become anything financial.
05Export and read-only sync. Approved orders export to Sheets. Zoho is read only: shops, items and prices come in, nothing goes out.
Key decisions

The choices that shaped it.

Each of these was a decision with an alternative, taken deliberately.

Decision 01

The application never writes to the accounting system

It reads shops, items and prices, and exports approved orders. The financial record stays human-controlled. This is the single most important boundary in the system and it was chosen deliberately, not by omission.

Decision 02

Clone and reorder over faster typing

Repeat orders are the common case in this trade. Cloning a previous order cut repeat entry from around two minutes to about thirty seconds, measured internally. That mattered more than any interface polish.

Decision 03

GPS confidence tiers, not a single reading

Location uses best-of-three with explicit confidence tiers, because one reading in a dense market street is frequently wrong and silently wrong is worse than visibly uncertain.

Decision 04

Dev and production isolation from the start

Separate environments before there was traffic to justify them, because retrofitting isolation onto a live order book is not a task anyone wants.

The boundary

Where AI is used, and where it is not.

Where AI earns its place
  • Nothing in the ordering path. The order flow is deterministic.
Where it never goes
  • Writing to the accounting system.
  • Approving an order.
  • Deciding a price.
  • Resolving which shop a GPS reading belongs to.
Operating model

What it takes to keep it running.

Production infrastructure runs at effectively zero monthly cost, with a defined order volume at which paid tiers become justified. API handlers were consolidated to stay inside plan limits rather than splitting into more functions than the plan allows.

Outcomes

What it changed.

Coming soon

Measured outcomes for this system are being compiled from our own operating records. We publish figures only once we can show how they were measured, so this section is deliberately empty until then.

Other work

More systems we built and run.

A useful first conversation

Show us the workflow everyone has learned to tolerate.

We will help determine whether it needs a focused product, an autonomous operating system, a stronger data layer, a review of what already exists, or a simpler fix that involves no AI at all.