KORA Sales on visit routes: from order to ERP with no paper

A sales representative on a food distribution route in the Lousada-Paços area today spends 40 minutes per stop filling in paper — order, signature, stock return, shelf photo. By the end of the day, 3 hours lost. By the end of the week, 15 hours. By the end of the year, 780 hours that never reach the ERP on the same day. Productivity per hour worked in Portugal is around 67% of the EU average — and much of that gap comes from processes that paper still governs. This guide shows how to eliminate that gap with KORA Sales: from the field order to the ERP record with no paper, no manual re-entry, no transcription error. At the end of this article you have an 11-point checklist to audit your visit route and identify where paper is costing you.

What you need before you start

Five conditions block most mobility projects. Check each one:

An ERP with a REST API or webhook to receive mobility data in real time is mandatory — without this, the order goes back to paper or email. Terminals or smartphones with 4G/5G or Wi-Fi connectivity are required, but offline-first is critical for rural areas: the representative cannot be left stuck when they leave Famalicão for the interior. Clearly defining who authorises orders (area manager, supervisor, VIP customer) is frequently forgotten — without this, the system gets stuck on exceptions and the representative goes back to phoning. A documented return process (which products come back, under what conditions, who signs) is rare in food distribution and causes phantom returns. Integration with your warehouse system — KORA Inventory or equivalent — to validate stock in real time separates those who save time from those who merely switch the paper support to a screen.

There are also two steps that seem administrative but are critical: the dynamic or fixed pricing policy must be decided before rollout (promotions, volume discounts, margins per customer), and the 2-hour training for each representative is not optional — it is the factor that most determines success or failure. We see projects where the system is good but the representative never learned to use it because the training was "watching a 30-minute webinar".

Step 1: Map your current visit route

Before any software, understand what you are doing today. Take a typical route for a representative and document: number of stops per day (average), time at each stop (arrival, conversation, order, signature, departure), how many orders per stop, how many customers refuse an order or return product, how many times the representative returns to the warehouse to restock or confirm a price, how many days a paper order takes to reach the ERP after being signed.

This is not theory. We see in INFOS projects that 60% of representatives lose 2-4 hours per week on administrative tasks that paper forces. Without this map, you cannot measure the gain — and without a measurable gain, the representative does not believe in the new system.

One detail the manuals do not mention: ask the representative how much time they spend "searching" for information — a customer that is not in the system, a product that changed code, a price nobody knows if it is valid. This invisible time is frequently 30-40% of the total time on paper. When the system brings the information to the screen, this time disappears, but the representative only recognises it after living the difference.

Verification checklist:

• Do you have the map of a typical route documented? (Yes/No)
• Do you know how much time is spent on paper vs. actual selling? (Yes/No)
• Do you have data on how many days an order takes to enter the ERP? (Yes/No)
• Did you ask the representative how much time they spend "searching" for information? (Yes/No)

Step 2: Define the data flow from the field to the ERP

The field order must reach the ERP without manual re-entry. This means: the representative enters customer, products, quantities, price on the terminal (not on paper); the system checks whether the customer exists, whether the product is in stock, whether the price is valid — all offline, without internet; when there is connectivity, the data goes to the ERP automatically (not by email, not by CSV file); the ERP responds whether it accepted the order or whether there is an error (customer blocked, insufficient stock, invalid price); if the order was accepted, the ERP generates the invoice automatically — no manual step.

This flow eliminates 3 common errors: order lost on paper (the representative loses the notepad, the order never arrives), re-entry with a digit error (the back-office employee writes "15 boxes" when the representative wrote "5"), a delay of days between sale and record (the order sits in a drawer until Friday).

Verification checklist:

• Does your ERP have an API or webhook to receive orders? (Yes/No — if not, it is a blocker)
• Do you have a plan for how the terminal works offline? (Yes/No)
• Do you know who validates and authorises orders in the ERP? (Yes/No)

Step 3: Configure the master data on the terminal

The terminal needs data that the representative consults constantly: customers, products, prices, stock. This data must be up to date on the terminal BEFORE they set off on the route.

If the terminal has out-of-date data, the representative makes wrong decisions in the field: offers a discount that does not exist, promises stock there is none of, sells to a blocked customer. This creates returns, complaints and rework. A real scenario: a representative in the Vale do Ave sells 10 boxes of product X to customer Y with a 15% discount. The next day, the warehouse discovers that product X was discontinued the previous week. The order is rejected. The customer phones furious. The representative's reputation takes a hit. All because the terminal did not sync the discontinuation.

Verification checklist:

• Do you have a plan for automatic synchronisation of master data? (Yes/No)
• Do you know who is responsible for keeping the master data up to date in the ERP? (Yes/No)
• Do you have a procedure to alert the representative if stock changed during the route? (Yes/No)

Step 4: Design the order screen on the terminal

The screen is what the representative sees. If it is confusing, they go back to paper within 48 hours. Design it with these rules: quick customer search with 2-3 characters of the name (no code needed), showing credit limit, outstanding balance, last purchase; product search by code, name or category, showing price, stock, sales unit (box, unit, kg); order line with customer + product + quantity + price = total, with no manual calculations; order summary before confirming (number of lines, total, discount applied, final total); customer digital signature on the terminal (or verbal confirmation and representative's signature, according to policy); optional field for a shelf photo (proof of visit, merchandising control); separate field for product returns (quantity, reason, signature).

The screen that works is the one the representative can use with one hand while holding a coffee. If it needs two hands or three clicks for a simple action, they go back to paper.

Verification checklist:

• Do you have a mockup of the order screen approved by the representative? (Yes/No)
• Does the screen show stock in real time? (Yes/No)
• Does the screen validate the credit limit before confirming? (Yes/No)

Step 5: Test offline-online synchronisation

Most routes in Portugal pass through areas without continuous 4G. The terminal must work offline and sync when there is signal. The flow is simple: the representative creates orders normally, without internet, and the data stays on the terminal; when the terminal sees 4G/5G or Wi-Fi, it automatically sends the orders to the ERP; if the customer was blocked between the offline order and the sync, the ERP rejects the order and the representative sees the warning; the representative sees which order was accepted and which was rejected, and why.

Test this with 10 real routes before national rollout. It is not rare to find areas where the signal is so weak that the terminal syncs only once a day — or where there are "dead zones" between Famalicão and Guarda where 4G disappears for 15 minutes. If the terminal is not prepared for this, the representative is left with orders stuck on the terminal and no way to send them until they get home.

Verification checklist:

• Did you test offline with 10 real routes? (Yes/No)
• Do you know which is the worst-coverage area in your region? (Yes/No)
• Do you have a plan B if synchronisation fails (e.g. data on the terminal, sent by email at the end of the day)? (Yes/No)

Step 6: Integrate with the warehouse and invoicing

When the order reaches the ERP, three things must happen automatically: the warehouse sees that there is a confirmed order and reserves the stock (does not let another customer take the product); the warehouse prints the picking list (or sees it on the terminal) and prepares the order; the ERP generates the invoice automatically (no need for an employee to do this manually).

If this is not automated, the time saved in the field disappears in the back-office. We see projects where the representative takes 5 minutes to place the order on the terminal, but the warehouse takes 2 days to process because it has no automatic notification. The warehouse manager prints the orders manually every 2 hours, or worse, the supervisor has to phone the warehouse to warn them there are new orders. This is not a software failure — it is a process failure. Before implementing mobility, define: who receives the order in the warehouse (automatic system or person?), how much time they have to process it (4 hours? 24 hours?), and how they communicate exceptions (insufficient stock, blocked customer) back to the ERP and to the representative.

Verification checklist:

• Does your ERP automatically generate the invoice when the order is confirmed? (Yes/No)
• Does the warehouse receive an automatic notification of a new order? (Yes/No)
• Do you have a defined maximum picking time (e.g. 4 hours)? (Yes/No)

Step 7: Define order quality control

Not every order is valid. Define automatic rejection rules on the terminal: customer with an outstanding balance above the credit limit; blocked customer (default, dispute, pending return); product discontinued or out of catalogue for this customer; quantity below the minimum order quantity (e.g. minimum 1 box, not 5 units); price outside the authorised range (e.g. a discount above 20% requires manager approval).

If the order fails one of these rules, the terminal shows the reason and the representative contacts the supervisor by phone (not by paper). The supervisor approves or rejects it in the ERP, and the representative sees the response on the terminal in real time. This mechanism is critical: without it, the representative is left stuck in the field and goes back to paper as a workaround.

Verification checklist:

• Do you have a documented list of rejection rules? (Yes/No)
• Do you know who approves exceptions (e.g. a discount above 20%)? (Yes/No)
• Does the terminal show the rejection reason in clear language? (Yes/No)

Common errors and how to avoid them

Error 1: Launching the system without up-to-date master data

Result: the representative sees wrong prices, wrong stock, customers incorrectly blocked. Goes back to paper within 3 days. Solution: carry out a complete audit of the master data (customers, products, prices, stock) 2 weeks before rollout. Fix errors. Sync to the terminal. Test with 3 real representatives for 3 days before expanding.

Error 2: Not training the representative

Result: the representative does not know how to use the terminal, gets frustrated, goes back to paper. Solution: 2 hours of in-person training with your representative (not a recorded webinar), using their route and their customers. They have to practise with real data. Then, follow-up by phone in the first 3 days.

Error 3: Expecting the representative to sync manually

Result: the representative forgets to sync, orders get stuck on the terminal, reach the ERP 24-48 hours late. Solution: automatic synchronisation when there is connectivity. The representative touches nothing.

Error 4: Not having a plan B for offline

Result: the representative loses signal, cannot create orders, sits in a café waiting for Wi-Fi. Solution: offline-first is mandatory. Test with 10 real routes without signal for 2 hours.

Error 5: Ignoring the warehouse

Result: the order reaches the ERP, but the warehouse does not know it exists. Picking takes 2 days. The representative's reputation takes a hit. Solution: before rollout, sit down with the warehouse manager and define: how they receive the order (automatic push, pull on the terminal, email), how much time they have to process it, how they communicate exceptions.

Frequently asked questions

How much time can a representative save per day by eliminating paper?

According to the example presented, a representative on a food distribution route spends 40 minutes per stop filling in paper. With several stops per day, that totals 3 hours lost daily on administrative tasks alone. By eliminating paper and automating the flow to the ERP, this time becomes available for actual selling activities.

What is the most important condition before implementing KORA Sales?

Your ERP must have a REST API or webhook to receive mobility data in real time. Without this, the order goes back to paper or email, cancelling out the benefits of digitalisation. This is a mandatory condition for the system to work correctly.

How does the system work when the representative has no connectivity?

The system must be offline-first, allowing the representative to record orders without internet. The data is synchronised automatically with the ERP when 4G/5G or Wi-Fi connectivity is available. This is critical for rural areas where network coverage is intermittent.

What is the minimum training time required for a representative?

Training must be a minimum of 2 hours per representative and is not optional. Projects where training was reduced to a 30-minute webinar failed. This is the factor that most determines the success or failure of the implementation.

What should you document before choosing the software?

You should map a typical route: number of stops per day, time at each stop, how many orders per stop, product returns, how many times the representative returns to the warehouse, and how many days a paper order takes to reach the ERP. Without this map, you cannot measure the real gain of the new system.

What errors does the automatic data flow to the ERP eliminate?

It eliminates three critical errors: orders lost on paper, manual re-entry with digit errors (such as writing "15 boxes" instead of "5"), and delays of days between the sale and the record in the system. All of this disappears when the representative records directly on the terminal.

How often should the master data on the terminal be updated?

Customers, products and promotions should sync daily before the route. Stock should update every 4 hours or before the route, depending on the volume of movement. Out-of-date data leads to wrong decisions in the field: invalid discounts, unavailable stock or sales to blocked customers.

Sources

• Eurostat — "Labour productivity by NACE Rev. 2 activity" — Data on productivity per hour worked in Portugal vs. the EU average (https://ec.europa.eu/eurostat)
• ISO/IEC 27001:2022 standard — Information security requirements for data management systems in mobility and ERP
• Directive (EU) 2014/65/EU (MiFID II) — Documentation and traceability requirements for commercial transactions applicable to sales systems
• CNPD (National Data Protection Commission) — Guidelines on the processing of personal data in mobility and CRM systems (https://www.cnpd.pt)
• INE (Statistics Portugal) — "Labour productivity in Portugal" — Reports on operational efficiency in distribution (https://www.ine.pt)