Build the operations screen on the data you already have

A rider calls support and asks where the chauffeur is. The answer is already in the system. The ride status is in the database, and the chauffeur's phone is already sending its location. The person on the call just cannot see it.

The usual answer is a second system

Most teams answer this with a new platform. Data is copied into it on a schedule, and someone rebuilds the workflows inside it. Now there are two copies of every ride. The copy is always a little behind, and every change to the business has to be made in two places.

The screen has to show what is true now

Support is on a call. A status that was right a minute ago is the wrong answer. So the screen cannot read from a copy. It has to read the system the apps write to.

Build the screen on the data the apps already write

The Sevenco operations desk keeps no copy of a ride. It listens to the same database and the same live channels the driver app already uses. A status change in the database updates the open ride. The chauffeur's phone already sends its location on a channel for that ride, and the desk joins that channel. New trail points are added to the route as they arrive. A location older than the one on screen is ignored, so the car never jumps back.

If the live connection drops, a backup check speeds up. When the connection comes back, the desk fetches once to fill the gap. The check stops when the trip is completed or cancelled.

The screen shows. A person decides.

A booking pause is one setting, and every open desk hears it at once. A new support ticket or a rider reply updates the badge straight away. Pausing the city and calling the rider back are still decisions a person makes.

The trail, the stale pin and the support inbox are in the Sevenco operations desk case study.

If your team needs a screen like this on top of the ERP you already run, that is the work of an ERP developer.