An existing tool or a custom system? Test the work before choosing.

Describe the decision without naming the software

A business wants a customer portal. Another asks for an ERP. A third wants everything moved out of spreadsheets. These requests name possible solutions before explaining the work. Start with a particular process: who receives information, who checks it, who approves a change, and who needs to see the result. Include the difficult cases. A software decision becomes clearer when you can show a real sequence rather than a collection of desired features.

Separate essential rules from familiar habits

Consider a hypothetical distributor serving customers in Saudi Arabia and the UAE. Its staff prepare quotations in two currencies, request approval for certain discounts and send order updates in the customer's chosen language. Currency handling, approval permissions and understandable documents may be essential. The position of a button in the old spreadsheet probably is not.

Write each requirement as an action and a check: “A salesperson can prepare a draft; only an authorised manager can approve the agreed exceptions.” Add expected volume, responsible roles and unusual cases. This makes a vendor demonstration much more useful than asking whether a product “supports sales”.

Compare three routes, not only buy versus build

The first route is configuring an existing platform: its fields, templates, roles and supported workflows. This suits work that fits the platform without extensive exceptions. The second is connecting existing tools, perhaps keeping the store and accounting system while transferring agreed information between them. The third is building a custom application or a focused module when necessary behaviour cannot be supported sensibly by the first two routes.

These routes can coexist. A business might use a standard customer-management platform and commission one approval interface around it. That is a more specific decision than replacing every tool. Ask which system owns each record and which component may change it; otherwise an integration can simply automate conflicting copies of the same data.

Make the demonstration follow your example

Prepare a small, anonymised set of representative work. Include an Arabic name, an English company name, a revised order and an action that the wrong role should be unable to perform. For a store, also test the actual payment and shipping arrangements you need against the provider's current supported options; a generic “e-commerce integration” label does not settle that question.

Ask the provider to show the complete path and identify which parts are standard, configured, supplied by an extra service or still proposed development. Record manual steps honestly. A manual approval can be appropriate; an undocumented manual step disguised as an automatic feature creates confusion later.

Include life after the launch

Compare recurring licences, implementation, integrations, migration, training and maintenance as separate responsibilities, even when the proposal presents one total. Ask how records can be exported, what happens when a connected service changes, who handles failed transfers, and who can maintain custom work if the original developer is unavailable.

For a bilingual team, also check how ordinary work feels: finding an Arabic customer, understanding permission errors, producing a readable document and searching records entered in either language. A translated menu does not establish that the complete process works. Review the location and handling of business data with the appropriate people for your organisation; do not infer suitability from a regional sales page alone.

Choose a bounded first release

If uncertainty remains, define one process and a review point. For the distributor, that might be quotation creation and discount approval for a small internal group, while the existing order process continues. Agree on what would justify extending the system and what would make you stop. A pilot should produce a decision, with its data and limitations recorded.

Before asking for a full platform quote, prepare one workflow, its owner, three exceptions and your existing tools. Explore Sabbk's platform and integration work. The right scope is the one that supports the work and leaves the business able to operate it.