EN Search Partner portal NavigatorTalk to an expert
HERALD POS solution

Choose a POS for a network of stores

Scope sales, catalogue, pricing, inventory, payment, returns, loyalty, closing and store continuity.

Take the assessmentNavigator
For: Retail, network, store operations, finance, commerce and IT leaders
01 · Short answer

What to clarify before discussing a solution

The signal

Stores apply different rules, till variances are analysed late and store inventory is unreliable for other channels.

The answer

Which store operations must continue when the network, a central service or an interface is unavailable?

The answer does not lie in an isolated feature: it is built by connecting rules, actors, data and evidence.
The expected outcome

A POS model testable through sales, exception and closing scenarios, with clear governance of central and local data.

02 · Structural decisions

Four decisions to make before configuration

These decisions make the scope testable and prevent structural choices from being discovered during the project.

01

Define pricing and authorisation rules

The decision must specify the rule, its owner, the required data and the evidence used to accept it.

02

Test sale, cancellation, return and closing

The decision must specify the rule, its owner, the required data and the evidence used to accept it.

03

Choose the data available in degraded mode

The decision must specify the rule, its owner, the required data and the evidence used to accept it.

04

Reconcile till, inventory and finance

The decision must specify the rule, its owner, the required data and the evidence used to accept it.

03 · Scope

A readable end-to-end flow

Scope is not a list of modules. It is a chain of events, ownership and decisions.

1Catalogue and central rules
2Sale and payment
3Return and credit
4Store inventory
5Closing and continuity

In the first scoping

  • One representative flow and its useful variants
  • Authoritative events and minimum data
  • Roles, decisions and escalation times
  • Acceptance criteria and baseline measurement

To sequence in waves

  • Additional sites, activities or populations
  • Rare variants that do not condition the pilot
  • Automations whose rule is not yet stable
  • Advanced dashboards after source reliability

To decide explicitly

  • Define pricing and authorisation rules
  • Test sale, cancellation, return and closing
  • Choose the data available in degraded mode
  • Reconcile till, inventory and finance
04 · Roadmap

From direction to measured improvement

  1. 1Navigator
  2. 2Personalised review
  3. 3Scoping workshop
  4. 4Wave-based deployment
  5. 5KPI measurement

Each stage produces a decision or evidence reusable in the next. Deployment remains business-led and verifiable.

05 · Metrics

Measure to decide, not to fill a dashboard

Every KPI needs a definition, a source, a cadence and an associated decision.

KPIFormulaSourceDecision
Conversion rateTransactions or orders ÷ visits or opportunitiesChannels, opportunities, baskets and ordersTarget breaks in the buying journey
Average order valueRevenue ÷ transactionsReceipts, orders and returnsAdapt assortment, offer and guidance
Stockout rateUnfulfilled demand ÷ total demandDemand, availability and allocationsReview allocation, thresholds and replenishment
Inventory accuracyItems without variance ÷ items checkedSystem inventory, counts and movementsCorrect the flows that create variances
Assessment

Assess your readiness

Six questions, an immediate reading and priorities adapted to your answers.

Start
06 · Business scenario

A store pilot that also tests exceptions

Situation
A network wants to standardise the experience without erasing local constraints in formats, payments and connectivity.
Approach
The pilot covers a complete store day, from data loading to closing, including sales, returns, network outage and reconciliation.
Target outcome
The decision accounts for continuity and operability, not only the sales interface.
This scenario illustrates a scoping method. Outcomes must be established with data from the selected scope.
07 · Frequently asked questions

Useful answers before the first discussion

01Where should we start in practical terms?

Choose a representative scope spanning “Catalogue and central rules” and “Sale and payment”, then document one normal case and one frequent exception. The first flow should be important enough to matter but contained enough to observe end to end.

02Do all existing systems need replacing?

No. Scoping starts with decisions, authoritative events and ownership. It then determines what should be retained, integrated, replaced or simply better governed, wave by wave.

03What data should be prepared before a workshop?

Prepare a few real cases, the volumes shaping the operation, the main variance reasons and the sources used to measure Conversion rate. The quality of examples matters more than the quantity of documents.

04How should the right pilot scope be chosen?

Choose a scope with an available owner, accessible data, a meaningful exception and a measurable outcome. Avoid both an overly simple case that proves nothing and an overly broad scope that dilutes learning.

05How can scope changes during the project be limited?

Make assumptions, interfaces, variants, exceptions and acceptance criteria explicit. Every new request can then be classified: essential to the wave, suitable for a later wave, or outside the objective. Discussion focuses on impact rather than intuition.

Next step

Turn this guide into a personalised review

Complete Navigator to position your context, then use the review as the starting point for a scoping workshop.

  1. 1Navigator
  2. 2Personalised review
  3. 3Scoping workshop
  4. 4Wave-based deployment
  5. 5KPI measurement
NavigatorPlan a discussion with an expert
08 · Continue

Complementary guides

Guides by suite
EMS Commerce suite

Unify omnichannel commerce

Connect catalogue, availability, order, payment, fulfilment, delivery, return and customer relationship.

  • Catalogue and pricing
  • Available-to-promise inventory
  • Order and allocation