Stall sales management system - the features you need

A stall sales management system should cover, in one place: a register of stalls, seller settlements, roles and permissions, and reports - ideally as a PWA running on the seller's phone in the field. The heart of such a system is not a pretty screen, but data consistency: who sold what, where, how much and how they settled it. Below are the features that genuinely prove their worth.

*We base this post on practice - we built such a system as a PWA for a real client.*

The features that are truly needed

• A register of stalls and locations with assignment to people.
• Settlements - takings, commissions, returns, in a way resistant to manual errors.
• Roles: owner/coordinator vs. seller - different views and permissions.
• Mobile / offline work - there is not always signal in the field. → What is a PWA
• Reports - sales over time, per stall, per person.

What buyers usually underestimate

The most pain is generated not by features, but by exceptions: corrections, returns, settlements across the boundary of days, permissions. They decide whether the system genuinely takes load off you or creates new paperwork. That is why we start with a well-sliced MVP and build out the exceptions based on real usage. → MVP in 6 weeks

Why a PWA and not a store app

The seller installs the system from a link, without waiting for store approval, and updates take effect immediately. For a small or medium-sized company this is a faster and cheaper rollout. → PWA for a small business

Typical problems of selling in the field

Stall and mobile sales follow a different logic than sales in a stationary store. The point of sale changes from one day to the next, handling is done by people working on their own, and the owner does not see in real time what is happening in the field. Specific pain points follow from this.

• A gap between takings and cash. Without a system the seller counts by hand, at the end of the day, often from memory. Small mistakes accumulate and it is hard to pin down where the difference arose.
• No real-time insight. The owner only learns the results after collecting the slips or making phone calls, usually with a delay of one or several days.
• Returns and corrections on paper. This is the place where abuse or a plain mistake is easiest, and at the same time it is hardest to trace who entered a change and when.
• Commission settlement. When pay depends on sales, manual commission calculations generate disputes and consume the time of the person settling the team.
• Seller turnover. Onboarding a new person on paper-based rules takes a long time and depends on memory rather than on a process.

The common denominator of these problems is the lack of a single, reliable source of data. Paper and spreadsheets do not enforce consistency - the same phenomenon we describe in the context of migrating from Excel to a system.

Key features of a field POS system

The features from the list at the start of this post are worth breaking down into what happens on the seller's screen and what the managing person receives. The seller needs a minimum of steps, the manager - a maximum of clarity.

At the level of a single transaction, speed is what counts. Choosing the product, the quantity, the payment method (cash, card, transfer) and confirming - the fewer screen taps, the fewer mistakes when there is a queue of customers. Every transaction should record a timestamp, the stall location and the person who entered it. Thanks to this, a return or correction always points to what it concerns.

At the management level, the split of roles is key. The seller sees only their own stall and their own settlement, the coordinator - the whole. Such a split is not only convenient, it is also an element of data protection and limiting permissions, which we expand on in the text about data security in an application. A report should answer simple questions without exports to a spreadsheet: how much in takings a given stall made this week, which person has the most returns, what the commission to be paid looks like.

It is also worth anticipating integrations up front. A stall sales system is rarely an island - the data flows to invoicing, accounting or payment handling. It is better to plan these connections at the design stage than to bolt them on later under pressure.

Offline work and data synchronization

The most often underestimated aspect of a field system is its behavior when there is no signal. A stall at a market, in a hall or at an outdoor event regularly loses connectivity, and sales must not stop because of it.

The solution is the offline-first model: the application saves transactions locally on the device and works the same way regardless of the network state. When the connection returns, the data synchronizes with the server in the background, without the seller's involvement. An important detail is the timestamp - the transaction keeps the moment of the actual sale, not the moment of upload to the server, so the daily report stays correct.

A second detail is conflict handling. If the same inventory item changes in two places, the system must have a clear rule for which data wins, instead of quietly overwriting one version. This is exactly the area of exceptions on which trust in the whole thing depends. Technically, this mode is provided by a PWA, which installs on the phone and works locally without a constant connection.

What implementation and team training look like

We run the implementation of a field system iteratively, not as one big launch. We start with an MVP that covers the most common path: new sale, return, basic settlement and report. We release this scope into real use at selected stalls, collect feedback and only on its basis do we build out the exceptions, additional roles and rarer scenarios.

Seller training is deliberately short. A person in the field uses just a few screens on a daily basis, so the introduction usually takes a single session of around fifteen to thirty minutes. More attention is required to train the coordinator, who uses the reports, manages permissions and handles corrections.

After launch comes maintenance: updates, minor changes to settlement rules, reacting to new needs. It is worth agreeing on these rules with the contractor before the rollout - we discuss this in the text about application maintenance after rollout. If you are wondering about the scope and cost of your own system, write to us - we will suggest where to start.

FAQ

Does such a system have to be an app from the Google/Apple store? No. A PWA installs on a phone directly from the browser, works offline and does not require store publication - which speeds up the rollout and lowers the cost.

Can we integrate it with invoicing? Yes, this is a typical integration. → Integrations: mail, invoices, payments

How long does it take to implement such a system? A working MVP - on the order of a few weeks. A full system with reports and exceptions - longer, iteratively. → How much a custom application costs

What happens to a transaction when there is no signal in the field? The seller keeps working. The transaction is saved locally on the device and is sent to the server automatically once the connection is restored, marked with the time of sale rather than the time of synchronization.

Can a single seller handle several stalls? Yes. The system assigns a person to multiple locations, while settlements and reports are split per stall, so the takings from each point stay separate despite shared handling.

How long does it take to train a new seller? With a well-designed interface, a single short session is usually enough, on the order of 15-30 minutes. On a daily basis the seller only uses a few screens: new sale, return and a view of their own settlement.