Digitising field processes: from paper to mobile application.

Ask a leadership team where its most important data is born. The answer is rarely “in the ERP”. It is born with the agent visiting a neighbourhood shop, on the site where cement is received, in the warehouse where pallets are counted, in the rural branch that opens an account or pays out an allowance, with the enumerator surveying households. What the system records afterwards is a copy, re-keyed later, by someone else, with a delay and errors. Digitising the field means having accurate data born once, where it happens.

Why paper and WhatsApp persist

It would be easy to see this as backwardness. It is rather a rational response to real constraints. Paper never runs out of network. It asks for no account, no password, no training. WhatsApp is already installed, the photo leaves in one gesture and the manager sees it straight away. Against that, many enterprise applications have failed for predictable reasons: they demanded a permanent connection, they reproduced a desktop form on a small screen, they added work for the agent without giving anything back, and they spoke a language that was not theirs.

Paper and WhatsApp nonetheless have a cost that always ends up being paid. The data arrives late, incomplete, impossible to match with the customer or the order in the system. Photos get lost in conversations. System stock never matches actual stock. Donors and auditors ask for evidence nobody can find. And knowledge of the field stays in the agents’ memory, and leaves with them.

What a field application must be able to do

A field application is not a smaller ERP. It is a tool designed for a precise context: a phone that is often entry-level, one free hand, an uncertain network, a user in a hurry. Five requirements follow.

• Work offline. The first condition, and the one most often sacrificed. The agent must be able to enter and consult their customers, their rounds, their stock, without network, for a whole day if need be. The application is local first, connected second.
• Synchronise cleanly. When the network returns, data goes out and comes back without intervention, in the right order, without duplicates, with clear rules when two people have changed the same thing. Synchronisation is the real technical heart of the project; it has to be designed, not endured.
• Capture photo and location. A time-stamped, geolocated photo is worth more than a long form: proof of delivery, state of a meter, progress of a site, presence of a point of sale. Location also helps organise rounds and check, without surveillance, that the visit took place.
• Stay simple. Few screens, big buttons, pre-filled lists rather than fields to type, smart default values. Every field added must be justified by real downstream use. If nobody reads the data, we do not ask for it.
• Speak the languages of the field. French, Wolof or another national language depending on the teams, with pictograms and, where necessary, audio messages. An application the agent understands without translating is an application they use.

Connecting the field to the core business system and the CRM

An isolated field application only moves the problem: instead of re-keying from a notebook, you re-key from a separate database. Value comes from integration. On the core business system side, the warehouse receipt updates stock in SAP or in Odoo; the order taken on the round becomes a sales order; the site record feeds project tracking. On the customer relationship side, the visit, the complaint or the point-of-sale survey enrich the record in Salesforce, so that head office and the field look at the same customer.

A few principles frame this integration. Master data stays in the master system: the list of customers, items and sites comes from the ERP or the CRM, the application does not recreate them. Exchanges go through documented APIs, with explicit error handling and retries. And it is decided at scoping what goes up in real time and what can wait for the next synchronisation. This is the ground of our Custom applications offering, from the mobile screen all the way to integration with SAP, Odoo and Salesforce.

A successful field application can be recognised by one sign: agents open it because it helps them, not because they were told to.

Change management with field teams

This is where most failures happen, and they are almost never technical. Field teams have seen tools imposed by head office come and go. They know the application can serve to monitor them as much as to help them. They are not won over with a memo.

What works, in our experience: involve a few agents from the design stage, not just at acceptance testing; give them something back from the first version, a round already prepared, a customer history at hand, the end of a report to redo in the evening; appoint relays in the field, colleagues who train their colleagues in their language; accept a period when paper and the application coexist; and correct quickly from each week’s feedback. Middle management counts as much as the agents: if the branch manager or the site foreman keeps asking for the paper form, the application is dead.

Security and personal data

A phone that travels in the field carries sensitive data: identities of customers or beneficiaries, contact details, locations, photos, sometimes amounts. It can be lost, stolen, lent. The application must therefore encrypt what it stores locally, open with authentication suited to the usage, keep on the device only what is needed for the day, and be wipeable remotely. Rights follow the role and the scope: an agent sees their area, not the country.

As soon as the application collects data about people, it enters the scope of Law No. 2008-12. The processing is declared to the CDP, the persons concerned are informed of the purpose, collection is limited to what serves that purpose, the retention period is defined. For collecting beneficiary data, these rules matter all the more because the persons concerned are often vulnerable. All of this is designed at scoping, not after go-live. Our IT security & risk offering steps in from that stage.

An iterative method, with a pilot

We do not believe in the big-bang rollout of an application designed behind closed doors. You choose a process and an area: a sales team on rounds, a warehouse, a branch. You observe the real work, on site, before drawing a single screen. You build a first version limited to the strict minimum, offline from the start, connected to the system on at least one flow. You put it in the hands of pilot agents within a few weeks, and you correct at their pace. You measure what matters to the business: delay between the visit and the data in the system, share of complete entries, matching stock, time given back to agents. Then you extend, area by area, taking along the relays trained during the pilot.

This way of working is consistent with what we are: a Dakar firm, whose teams can go into the field, test with the agents in their language and come back the following week. Designing a field application for the sub-region from the sub-region is the condition for it to take into account the real networks, phones, languages and habits. The data that comes out of it then feeds reporting, the subject of our Data & Analytics offering, and sometimes the first AI & automation use cases, reading photographed documents first among them.

Our recommendations

1. Start from a process, not an application. Which field action produces the data the company needs most? That is where you start.
2. Require offline operation and synchronisation from scoping. These are the two points you cannot catch up on afterwards.
3. Decide on integration early. Which master data comes from SAP, Odoo or Salesforce, which flows go up, at what pace.
4. Design with the agents and field management. Give them time back from the first version.
5. Treat security and Law No. 2008-12 as product requirements. Encryption, rights, declaration to the CDP, information of the persons concerned.
6. Pilot, measure, extend. One area, a few weeks, business indicators, then rollout in waves.

From paper to mobile application, the path is not primarily technological. It consists in respecting field work as it is, giving it a tool that serves it, and finally connecting what the company does to what it records.