Mandatory requirements come before tool comparisons. An unknown API permission, contract condition, or data restriction stays “needs verification.” We do not record it as an assumed yes or assign it a false score.
1. Define the operational result
We start with the process. The brief names the event that starts the work, the expected result, the system of record, the process owner, and the person who handles exceptions.
We review recent real cases, including delays and reversals. If the team cannot agree on the rule, we document the policy before adding automation.
2. Map systems, data, and ownership
For every step we identify what reads or writes data, which edition is in use, how access is granted, and who owns the credential or connection. We also record volume, peaks, required response time, sensitive data, audit needs, and the manual fallback.
The map separates a product’s general capability from the access available in your environment. “The ERP has an API” is incomplete until we confirm the required action, edition, permission, and operating conditions.
3. Check which options are eligible
An option stays in consideration only if it can perform the required actions within the company’s permissions, contracts, data rules, and maintenance capacity. A lower price or impressive demo cannot make up for a missing requirement.
| Requirement | Evidence sought | If it is missing |
|---|---|---|
| Functional access | Connector or API action for the required read/write | Verify with the vendor, administrator, or a bounded technical check |
| Permission and contract | Edition, scopes, region, and allowed use | Keep the option conditional or remove it from the proposal |
| Data governance | Approved data movement, retention, audit, and identity model | Redesign the flow before building |
| Operability | Named owner, monitoring, recovery, and change path | Add the operating model to scope |
| Validation | Baseline, representative cases, and acceptance rule | Define measurement before the pilot |
4. Compare only viable architectures
We look for the smallest reliable option. It may be a native feature, a managed automation platform, an API-oriented orchestrator, an AI-assisted step, a custom connector, or focused software. The proposal explains where each option fits, what remains unproven, who maintains it, and which fact would change the recommendation.
The cost review includes implementation, licenses, API or AI consumption, hosting, maintenance, migration, and recovery. Vendors count actions, executions, and credits differently, so we do not treat those units as directly interchangeable.
5. Validate a reversible pilot
Before launch, we agree on representative cases, missing data, duplicate events, timeouts, rejection paths, and safe recovery. The process owner checks the expected result in the system of record. The pilot keeps a manual fallback and a way to pause the workflow.
We label evidence according to what happened:
| Label | Meaning |
|---|---|
| Documented | Current primary documentation supports the claim |
| Technical check | We inspected a specific action or type of access in the target environment |
| Pilot | The bounded workflow ran on an agreed set of cases |
| Production observation | A live process was measured for a stated period |
A vendor claim or documentation review is not described as Kiia’s benchmark. Results are reported with their scope, denominator, period, and exceptions when those observations exist.
6. Hand over operation and decide what comes next
The handoff covers the flow, access assumptions, logs, alert route, exception owner, recovery steps, pause mechanism, and responsibility for changes. The review uses the agreed baseline and acceptance rule. Automation alone does not prove that the process created business value.
What the first workflow reveals determines the next step. The team may add another integration, strengthen monitoring, improve source data, or stop until a system constraint is resolved.
For a practical example of how the method changes a recommendation, see Teams and ERP approvals. The systems integration service explains the corresponding engagement, and our guide to Power Automate, Copilot, and custom development adds detailed platform context.