The Business Decisions That Should Come Before an AI Implementation

A proposal to introduce AI can attract agreement before anyone has settled what the business intends to change. Operations wants faster processing, relationship teams want better service and technology wants a capability it can support. Each objective is reasonable. Together, they can produce a project whose success is difficult to define.

The leadership task is to make those choices explicit. An implementation needs a specific outcome, a workflow that can change and people with authority to resolve the trade-offs.

For financial services firms, this work should begin before a product demonstration becomes the project brief. The decisions made at that point shape scope, cost, adoption and whether the result improves the business.

Key takeaways

• Agree on the service or operating outcome and the conditions that must remain acceptable as it improves.
• Assign a business owner with authority over the workflow, alongside technical and risk responsibilities.
• Fund an evidence-based first release, including integration, adoption, review effort and ongoing operation.

1. Choose the Outcome Worth Funding

A strong investment brief names a business problem and the evidence that it matters. “Reduce the time from a complete application to operational review” is more useful than “deploy an onboarding agent.” It defines a result that can be observed independently of the technology.

Specify the boundaries around the outcome. Faster handling should not come at the expense of material accuracy, appropriate customer treatment or an unmanageable review burden. These conditions belong in the acceptance criteria from the beginning.

The sponsor should also explain why this problem takes priority now. A visible inconvenience may be less valuable to address than a recurring handoff that constrains an entire service journey.

2. Decide Which Process Is Allowed to Change

AI projects can become expensive attempts to accommodate every existing workaround. Before delivery begins, determine which steps can be simplified, which records are authoritative and which approvals are necessary for the work being performed.

Use actual cases to ground the discussion. If information is re-entered three times, understand why. One copy may support a separate business requirement; another may exist because two teams have never agreed on ownership. The solutions are different.

Document both the intended process and the exceptions. A design that works only when every document arrives together may fail in normal operations. Include the cases that are incomplete, unusual or waiting on an external party.

This creates a practical scope boundary. The first implementation can improve a defined segment of the process while recording dependencies that belong in later work. Leaders should know which bottlenecks will remain after release.

3. Assign Ownership Where Decisions Are Made

A project sponsor can approve funding without controlling the workflow. Successful implementation also needs a business owner who can agree on completion standards, change team practices and resolve conflicting requirements.

Technology owns the reliability of the solution within its remit. Risk, privacy and security specialists assess the relevant requirements and controls. Operational leaders allocate review capacity and determine how the team handles exceptions. These contributions need a shared decision process.

A governance meeting is useful when it resolves these decisions. Adding committees without assigning authority can prolong the same uncertainty the project is meant to address.

4. Establish the Data and Integration Reality

Before committing to a delivery estimate, test access to the records the workflow depends on. Confirm where information lives, who can use it and whether supported interfaces exist for the required actions.

Data readiness is specific to the task. A document collection may be sufficient for preparing a draft summary while remaining unsuitable for updating a customer record automatically. Historical information may be useful for context but too stale to support a current decision.

The implementation brief should distinguish verified facts from assumptions. A dependency on a vendor interface, a restricted portal or an unfinished data-cleaning effort can materially change the scope and timetable.

It should also identify the exit path. The firm needs a usable copy of its business rules, evaluation cases and relevant operational records if a supplier changes or the solution is retired. The degree of portability required is a commercial decision that belongs in the design.

5. Choose the Smallest Release That Tests the Case

A first release should be narrow enough to deliver and substantial enough to test the intended outcome. Automating a trivial task may demonstrate the software without answering whether the investment is worthwhile.

For an onboarding process, a useful initial scope might cover one document type, one service team and a defined completeness check. It would still include review, exceptions and the handoff to the next stage. Those elements are necessary to measure the complete task.

Compare delivery options against the same requirements. Existing platform capabilities, specialist software and a custom integration may each have a role. The comparison should include support effort, data access, workflow fit and the cost of adapting the solution over time.

6. Fund Adoption and Operation Explicitly

The purchase or build cost is only part of the investment. Staff need time to learn the workflow, reviewers need capacity to check outputs and service owners need a way to investigate failures and maintain the system.

Include these costs in the business case. Also separate cash savings, released capacity, service improvements and potential revenue effects. They are different benefits and should not be added together without checking for overlap.

For example, time released from document handling cannot simultaneously be counted in full as a staffing saving and as additional capacity for new customers. The leadership team needs to choose how the benefit will be realised.

Agree on a review date and the conditions for continuing, changing or stopping the implementation. A decision to discontinue a weak use case can preserve resources for a stronger one. It should be available as a normal investment outcome.

7. Turn the Brief into an Operating Agreement

Before delivery begins, the sponsor, process owner and delivery team should be able to describe the same outcome, scope and responsibilities. Differences at that point are cheaper to resolve than differences discovered after the system is in use.

Retain the agreement as the project evolves. When a new data source or action is proposed, assess its effect on value, permissions, support and acceptance criteria. Scope can change, but the reason and consequences should remain visible.

AI implementation then becomes a managed business change with a clear basis for judging results. The technology team can deliver against a coherent brief, and leaders can decide whether the outcome warrants the next investment.

Define the Business Case Before You Build

Bring an AI opportunity and the operational problem behind it to a discovery conversation with SENNSE. We can help clarify the outcome, workflow, ownership and evidence needed for a practical first release.