Investigate an internal system when a recurring process depends on permissions, approvals and controlled states that your current tool cannot manage practically. A large worksheet or a desire for a polished dashboard is not enough. If the data is dependable and responsibilities are clear, improving the spreadsheet may be sufficient. If a ready-made product meets the need, test it before commissioning custom software.
For a growing Saudi business, start with one defined process: a branch service request, document approval or operational task. Establish its beginning, end and owner before deciding whether you need an internal operations system and dashboard. Avoid turning the first discussion into a replacement programme for every company system.
1. Is the problem reporting or getting work done?
Ask: “If we had the requested report right now, would the blockage disappear?” If so, data cleaning, a consistent metric definition or a read-only dashboard may be enough. If staff do not know who approves a request, or people can make changes they should not be allowed to make, the process needs attention.
Distinguish three deliverables:
| Deliverable | What it provides | What not to assume |
|---|---|---|
| Organised spreadsheet | Data, calculations and simple tracking | That it enforces every required business rule and permission |
| Reporting dashboard | A view of data for management review | That it processes a request or records an operational approval |
| Operations system | Controlled entry, states, permissions and agreed actions | That it replaces accounting, HR and enterprise ERP |
A suitable solution may combine existing software, a dashboard and spreadsheet exports. Retaining spreadsheets for analysis is not a failed transition. The problem is competing sources for the same operational record.
2. When is a better spreadsheet enough?
Keep the spreadsheet when the process is straightforward, responsibilities are understood, errors have limited consequences and entry and review can be controlled without awkward workarounds. Try one authoritative version, stable record identifiers, validation rules, consistent status definitions and a named data owner.
Do not confuse cell protection with confidentiality. Google explains that Sheets protection is not a security measure, and hidden sheets can be revealed by editors. If branch staff must not see another branch’s records, verify actual access controls instead of merely hiding a tab. Source: Google Sheets protection and hiding.
Record real failures before choosing a replacement: a lost request, undocumented approval, duplicate record or conflicting edit. Avoid universal thresholds such as “you need a system after ten employees.” The process and information involved matter more than headcount alone.
3. Compare four options using the same task
Ask each option to complete one end-to-end scenario using test data rather than sensitive business information.
| Option | When to investigate | What to test |
|---|---|---|
| Improve the current spreadsheet | A simple process with few rules | Authoritative data, entry validation and sharing boundaries |
| Off-the-shelf software | A common process such as requests or task management | States, exceptions, export and permissions in the proposed plan |
| Configurable or low-code platform | A bounded need that fits its capabilities | Recurring costs, integrations, data limits and exit options |
| Focused custom system | An important gap demonstrably unmet by alternatives | Operating ownership, maintenance, tests and data portability |
Compare completed work, not screenshots. Test the ordinary journey, a rejection and a change after approval. Include subscriptions or development, data preparation, connections, training, support, future changes and eventual migration in the cost comparison.
4. Specify the process before designing the dashboard
Document the trigger, required information, permitted states, decision owners, expected timing under your own policy and exception paths. Identify the authoritative system for each field. Do not create a second source for information another system already owns without a clear reason.
Product discovery and requirements should produce something testable: who acts on which record, when it moves to the next state, and what happens after rejection or a failed connection.
Then test a prototype with the people doing the work, not only management. An employee may need a clear daily work queue more than a chart. User experience design helps arrange tasks and error states before they are embedded in software.
5. Worked example: maintenance requests across Saudi branches
This is an illustrative example using test data, not a LAB project or reported result. A business has branches in Riyadh and Dammam. Maintenance requests arrive through messages, and one employee updates the tracking spreadsheet. The business decides to pilot a maintenance-request portal while leaving accounting and purchasing in their current systems.
The first release covers request creation, supporting details, supervisor review, assignment and closure. Payroll, invoicing and stock-system replacement are explicitly excluded.
Example permission matrix
| Role | Allowed actions | Actions that must be prevented |
|---|---|---|
| Branch employee | Create a request and follow permitted records | Approve their own request or view an unauthorised branch |
| Branch supervisor | Accept or reject branch requests with a reason | Alter a past approval without retained history |
| Operations coordinator | Assign, monitor and close under agreed rules | Close a request without required completion information |
| Reviewer | View and export within their scope | Edit requests or approve them |
A hidden button does not prove that a permission is enforced. OWASP recommends least privilege, denial by default and authorisation checks on every request. Testing should therefore include forbidden-access cases within an authorised environment and scope, not just inspecting visible menus. Source: OWASP authorisation guidance.
How do you know the dashboard total is correct?
Assume eight test requests: three drafts, two under review, two approved and awaiting work, and one closed. If the business defines “active” as under review or approved but not closed, the correct total is four, not seven or eight.
The “four active requests” card should lead to those same four records while respecting branch access and date filters. Change one request’s state and check that the list and card remain consistent. This tests source-to-screen reconciliation rather than the appearance of a report.
6. Acceptance tests that prevent surprises
Define the tests before approving implementation:
- A complete request travels from creation to closure with the actor recorded for each action.
- The requester cannot approve their own request if policy prohibits it.
- A user cannot access an out-of-scope record, including through a direct link.
- A rejection includes its reason and an understandable correction and resubmission path.
- Two simultaneous editors cannot silently overwrite a newer change with an older one.
- Dashboard totals match source records, filters and status definitions.
- Failed integrations or notifications are visible to the responsible person; retries do not create duplicates.
- Required Arabic mobile layouts, fields, dates and error messages are tested.
- Agreed data can be exported, action history reviewed and a backup restored under the defined plan.
If another application supplies data, specify update direction, frequency, permissions and conflict ownership. API integration and development can cover this work when the necessary interfaces and authorisations exist. The presence of an API does not mean every connection is unrestricted or feasible without investigation.
7. Migrate deliberately and assign operating ownership
Start with cleaned records and an explicit treatment of duplicates and missing fields. Reconcile record counts and a sample of their contents. Decide what moves and what remains in a read-only archive. Every historical file does not need to become a new application feature.
During the pilot, name the authoritative operational source and a method for resolving differences. Parallel running without this rule creates competing records rather than evidence that migration is working. Expand after tasks, permissions and reconciliation pass and staff can use the system, not simply when screens are complete.
Request an issue register and software quality assurance results, instructions for user administration, backups and exports, and an owner after handover. Even a small system needs someone responsible for it. Avoid making every routine change dependent on one implementer’s memory.
Frequently asked questions
Does a dashboard mean we have an operations system?
No. A dashboard may display file data without controlling creation or approval. Identify where the task is performed and where the rule is enforced, then define the dashboard’s role.
Is custom software always better than ready-made software?
No. A ready-made product may cover the process with less implementation and operating effort. Custom work becomes justified when testing establishes an important gap and there is a credible plan to operate and maintain the result.
Must we stop using Excel entirely?
No. Keep it for analysis, planning and exports where useful. Make sure an analytical copy does not become a competing editing source for the authoritative operational record.
Can we connect accounting later?
Possibly, depending on the existing system, its interfaces and permissions. Separate that integration from the first release and define the data, ownership and reconciliation tests. A one-process portal is not an ERP implementation or an accounting-assurance service.
Your next step
Choose one process that is failing today. Collect an example request, a rejection and a data conflict. Ask for a practical comparison of improving the current tool, configuring ready-made software and building a bounded solution, using the same acceptance scenario for each.
Sources
Reviewed on 26 October 2026.
