Start with the systems your business already runs

Describe the outcome before the application

Write down the work a solution must complete, the evidence it must use and the point at which a person accepts the result. For an order-to-invoice workflow, that might mean assembling consistent order and fulfilment records so an authorised reviewer can resolve a held invoice.

Keep the required outcome separate from a preferred technology. Some steps may suit AI; others may need a straightforward rule, better integration or a change to how information is captured. The workflow gives you a consistent way to assess each option.

Inspect the existing environment

List the ERP, document stores, communication channels and other systems involved. Ask the relevant owners what features, configurations and connections are actually available. A capability described in a vendor demonstration may depend on an edition, region, licence or integration your business does not currently use.

Check with the existing system partner where appropriate. Confirm supported interfaces, access requirements, usage charges and the effect of an upgrade. Record what has been demonstrated in your environment and what still needs a test. Treat assumptions as open questions until there is evidence.

Compare the full cost of operating

Subscription price is one part of the decision. Include setup, integration, data preparation, staff training, human review, monitoring and support. Consider who will maintain a connection when an upstream system changes and who will investigate an incomplete transaction.

Compare options using a common set of representative cases. Look for correct completion, useful exception handling and an understandable operating process. Record the effort needed to reach the result, including work that happens outside the application.

• A process improvement using the current systems.
• Suitable native features and existing integrations.
• Specialist software with verified fit for the workflow.
• A bounded custom component for a remaining, evidenced gap.

Give custom development a specific job

When a gap remains, describe it precisely. A small component that connects an evidence source or routes a particular exception is easier to assess than a new platform intended to cover every future requirement. Define the boundaries, interfaces and owner before building.

Use the same acceptance criteria for a proprietary component as for a third-party tool. Confirm that the benefit justifies development and continuing support. Repeated demand from similar customers can inform a future product decision, but a useful feature in one engagement does not establish that demand.

Keep the customer in control

Before committing, agree how configuration, data and operating records can be accessed and exported. Identify any restrictions, dependencies or costs involved in changing suppliers or returning to the previous process. Make the responsibility for licences and accounts explicit.

The result of the selection should be a clear implementation choice, with its costs, limits and reasons. A customer should be able to understand why the chosen tool belongs in the workflow and what is required to keep it useful.