Start with the process you need to improve, then ask each company how it would build, test and hand it over. A polished proposal alone does not establish fit. This guide helps business and IT teams compare equivalent proposals for an internal system serving Saudi organizations, including Arabic and English use, without relying on a promotional vendor ranking.
Give every shortlisted team the same scenario
Illustrative example, not a customer project: an employee submits a purchase request with an attachment; a department manager reviews it; finance reviews requests above an organization-defined threshold. Add an exception: the manager is absent, or the amount changes after approval. Ask for states and permissions before discussing technology. Questions about exceptions expose scope more clearly than a screen count.
- Who owns the request in each state, and who can see its attachment?
- What happens on rejection, delegation or changes to an approved amount?
- Which system owns employee and budget data, and how does an integration failure surface?
Evaluate evidence before promises
Ask for a walkthrough of a comparable flow, clearly distinguishing a live product, a prototype and a configurable foundation. A screenshot does not prove a customer deployment. For a named client, metric or certification, ask for evidence that can be shared with permission. Test long Arabic labels, field direction, amounts and dates on a phone, then repeat the task in English.
- Record each result as demonstrated, documented only, or not yet established.
- Have the operational owner evaluate the task alongside IT.
- Do not score an unsupported assertion the same as inspectable evidence.
Make handover part of the comparison
Specify the handover in writing: the repository if included, build and deployment instructions, data model, integration documentation, account administration, and backup and recovery plan. Separate ownership of custom code from third-party licenses. These are items to agree, not automatic inclusions in every proposal. Also define defects, change requests, release acceptance and support ownership.
- Who administers the domain, hosting and accounts?
- How will your team test a release before accepting it?
- What support hours and channels are agreed, and what is excluded?
Turn the evidence into a defensible decision
Share the scorecard with decision-makers before meetings. Use a zero-to-two scale: zero for no evidence, one for a documented answer, two for a demonstration or inspectable deliverable. Establish non-negotiables first, such as document permissions or an agreed handover. Do not let a total score hide failure on a critical requirement. Convert open assumptions into scope questions before fixing price and schedule.
A scorecard to complete for each vendor
| Criterion | Evidence to request | Clarification trigger |
|---|---|---|
| Process understanding | States, exceptions and an owner for each step | Pricing before exceptions are understood |
| Bilingual experience | The same task in Arabic and English on a phone | Translated labels without direction testing |
| Integration and access | A data owner and a denied-access test | Any-system integration promised without inspection |
| Handover and operation | Deliverables, acceptance and support owner | Unclear accounts or licenses |
The next step
Send the chosen team your process summary and critical exceptions: a useful starting point for a custom system discussion.