An illustrative scenario. The site and people are composites.
A shipment booked at a freight brokerage near Dubai gets typed in six times before anyone bills for it. Sales enters it in the quote sheet, operations copies it into the booking sheet and the legacy TMS, and finance types it again into the billing, margin and customs record sheets. This scenario follows one such brokerage from a first look at the problem to an ordinary week on a custom web application, where each shipment is entered once and every team reads the same record.
THE SITE
A 150-Person Freight Brokerage Running On Copied Data
The brokerage has 150 people and moves between 250 and 400 shipments a week. Every shipment record passes through five spreadsheets and a legacy transport management system. Each team keeps its own copy of the data, so nobody can say which copy is right.
Sales keeps a quote sheet. Operations keeps a booking sheet and works the legacy TMS, which carriers and customs filings depend on. Finance keeps a billing sheet, a margin sheet and a sheet of customs records for lanes into the United Kingdom. A consignee's name, a container number, a weight or an agreed rate is typed by hand at each step. When a booking changes, someone has to find and correct every copy. The operations lead describes it as chasing the same shipment around the building.
Public research has found the same pattern. The UK Department for Science, Innovation and Technology's 2026 study of business data use found that manual data entry is one of the key sources of inaccurate or inconsistent business data, and that businesses worry about human error in entry work nobody checks. An interviewed manufacturer told the study that an error in one part of a spreadsheet table can generate errors downstream. Another business said its biggest slowdowns came from software that does not integrate. The academic record is no kinder. Panko's review of spreadsheet error research, published through arXiv from the EuSpRIG proceedings, found that fifteen years of studies agreed unanimously that spreadsheet errors are common and non-trivial. It also found that cell-by-cell code inspection was the only method shown to catch them reliably.
THE CONSTRAINTS
What The Brokerage Cannot Change
The brokerage has to keep its legacy TMS, keep its shipment data on infrastructure it controls, and keep customs records for the full legal period. Any new system has to work within those three limits.
The TMS stays because carrier bookings and customs filings run through it, and replacing it would be a separate project with its own risk. It has no modern interface for other software, so the new application has to reach its data some other way. The IT lead wants shipment and customer data kept on the brokerage's own server, partly because customer contact details fall under the UAE's federal data protection law. Finance has a records duty on its UK lanes. HMRC's notice under the Customs (Records) (EU Exit) Regulations 2019 requires a trader to keep records of goods it imports, exports or declares for 3 years after the last day of the year the record was created, by default. A shipment record that lives in five places can be found and produced only by hand.
THE DESIGN
One Shipment Record, Entered Once, Read By Every Team
The design puts one web application on the brokerage's own server, holding a single shipment record. Sales, operations and finance each work in their own screens on that record, and a connector keeps the legacy TMS in step.
ARSA's custom web application service describes this kind of build as an enterprise operations platform. It brings fragmented processes together in one place, with real-time dashboards drawing on several data sources, workflow and approval engines, and role-based access with audit trails. On hosting, the service page answers either way and states that on-premise and air-gapped deployment are both supported. For this site the application runs on the brokerage's own server. The feasibility assessment decides how the connector reaches the TMS, since ARSA's page says the integration surface is set at that stage, including for a legacy system that has no API.
Read As Text
- Sales Quote Screen leads to Single Shipment Record (enter once)
- Operations Booking Screen leads to Single Shipment Record (add booking)
- Finance Billing Screen leads to Single Shipment Record (bill)
- Single Shipment Record leads to TMS Connector
- TMS Connector leads to Legacy TMS (keep in step)
- Single Shipment Record leads to Brokerage Server On Site (stays on site)
- Brokerage Server On Site leads to Audit Trail
- Brokerage Server On Site leads to Operations Dashboard
- Brokerage Server On Site leads to Customs Record Archive (retain)
| Item | Before | After |
|---|---|---|
| Places each shipment is typed | 6 | 1 |
| Spreadsheets holding shipment data | 5 | 0 |
| Shipments a week (assumed range) | 250 to 400 | 250 to 400 |
| Record of who changed what | None | Audit trail on every record |
| UK customs record retention | 3 years, across five sheets | 3 years, in one searchable record |
| Where the data lives | Shared drives and laptops | The brokerage's own server |
THE ROLLOUT
From Feasibility Assessment To Go-Live
The rollout starts with a feasibility assessment and then follows ARSA's five development phases, each with a defined deliverable. ARSA's page puts the phases at 1 to 2 weeks for discovery, 2 to 3 for design, 6 to 12 for development in 2-week sprints, 2 to 4 for integration and testing, and 1 to 2 for deployment and training.
The feasibility assessment comes first and runs for 2 weeks. It produces a written diagnosis, a technical feasibility judgement and a go or no-go recommendation, and it settles the data model, the TMS integration route and the permission model before any code is written. Discovery then maps the actual journey of a shipment through all five sheets, including the columns that exist only because one team does not trust another team's copy. In design, the brokerage gets clickable screens that sales, operations and finance can test. Development delivers working modules in staging, with a demo every two weeks. Integration and testing connects the TMS and runs user acceptance on real shipments. Deployment ends with trained users and documentation.
ARSA delivers outside Indonesia. Where visa conditions keep its engineers from travelling, a qualified local partner works on site under ARSA supervision.
Read As Text
- Feasibility Assessment Two weeks to set the data model, the TMS route and permissions, ending in a go or no-go.
- Discovery And Requirements One to two weeks mapping each shipment's path through the five sheets.
- Design Two to three weeks of screens that sales, operations and finance can click through.
- Iterative Development Six to twelve weeks in two-week sprints with a demo every sprint.
- Integration And Testing Two to four weeks connecting the TMS and testing on real shipments.
- Deployment And Training One to two weeks to go live with trained users and documentation.
A DAY IN OPERATION
What An Ordinary Week Looks Like
On an ordinary day each team works on the same shipment record in its own screen, and changes reach every other team without anyone copying them. Each team's job looks a little different.
Sales
A salesperson enters the consignee, route and agreed rate once, while quoting. If the customer accepts, the quote becomes a booking request with no retyping, and the salesperson can see its status without asking anyone.
Operations
The operations team opens the booking that sales created, adds the carrier and container details, and the connector passes them to the TMS. If the shipment changes, they edit the record once and the audit trail notes who made the change and when.
Finance
Finance bills from the same record, sees the margin against the agreed rate, and finds any UK shipment's customs record by searching for it. Month end becomes a review of exceptions the dashboard flags, and the hunt for the right copy goes away.
ARSA has no footage catalogued for this service, so this scenario shows none.
WHAT IT COULD CHANGE
Hours Back, And One Record To Keep
Taking out five of the six entries for each shipment frees between 41.7 and 133 hours of re-keying a week. That works out to between 2,167 and 6,933 hours a year, or about 1.0 to 3.3 full-time roles at 40 hours a week. The low end assumes 250 shipments a week at 2 minutes an entry. The high end assumes 400 shipments at 4 minutes.
The brokerage would also hold between 39,000 and 62,400 shipment records inside the 3 year UK retention window, one copy of each, searchable from a single screen. These figures cover labour and record keeping only. The scenario has not happened, so there is no measured error rate to report, and this article gives none.
View The Data
| Outcome | How It Is Worked Out | Low | High |
|---|---|---|---|
| Re-Keying Hours Freed Per Week | Shipments a week, entries removed, minutes per entry | 41.7 hours | 133 hours |
| Re-Keying Hours Freed Per Year | Weekly hours freed across 52 weeks | 2,167 hours | 6,933 hours |
| Full-Time Roles Of Re-Keying Freed | Weekly hours freed divided by contracted hours per person | 1 full-time roles | 3.3 full-time roles |
| Shipment Records Inside The UK Retention Window | Shipments a year times the default retention period | 39,000 records | 62,400 records |
THE LIMITS
What The Application Does Not Do
The application cannot clean up the data already sitting in the spreadsheets, cannot replace the TMS, and cannot catch every error by itself. Validation at the point of entry stops some mistakes, but people still have to check quotes, rates and customs details.
The migration needs someone to choose which of five conflicting copies of an old shipment is the true one. Panko's review is a reminder that only careful inspection has been shown to catch spreadsheet errors, so a review step on high-value fields stays in the workflow. The hours range moves with shipment volume, with the true minutes per entry, and with how many of the six entries the brokerage actually makes for each shipment, since some teams skip one when they are busy. In the first months, the operations lead would time entries before and after go-live, count shipments each week, and log corrections made after billing. That would show where in the range this site lands.
THE CHECKLIST
Design Checklist For A Single-Record Rebuild
The checklist below lists the site requirements this scenario needed before development could start. Print it and tick it off with the people who own each sheet.
FAQ
Frequently Asked Questions
Why Build A Custom Enterprise Web Application When Spreadsheets Already Work?
Build one when the same record is retyped in several places and nobody can say which copy is right. Spreadsheets work for one team. Across several teams they copy data by hand, and the UK government's 2026 study names manual entry as a key source of inaccurate business data.
What Is The Difference Between An Enterprise Application And A Web Application?
An enterprise web application is a web application built for an organisation's internal operations. It typically has role-based access, audit trails, approval workflows and integration with existing systems. A general web application may need none of these. The browser delivery is the same in both cases. What changes is the controls around shared data.
Can A Custom Web Application Work With A Legacy TMS That Has No API?
Yes, in most cases. ARSA's page states that the integration surface is set during the feasibility assessment, including where the legacy system has no API and needs a different approach. The assessment names the route before any code is written.
Where Is The Data Hosted?
On infrastructure the client chooses. ARSA's page states that the client can host the application or ARSA can, with on-premise and air-gapped deployment supported, and that most enterprise clients host it themselves.
Who Owns The Code Once The Application Is Built?
The client usually receives the custom application code, as agreed in writing before work starts. ARSA's platform components and reusable libraries are licensed to the client and stay ARSA's.
For a closer look at how these builds run from assessment to go-live, read Enterprise Web Applications for further reading, and get in touch if your teams are retyping the same record in several places.
