A complete proposal should let a leader who missed the sales conversation understand what work will change, what result the firm is buying, what the firm must provide, what it will cost and who controls the capability after launch.
An AI implementation proposal should let someone who missed the sales conversation understand what the firm is being asked to approve.
That person may be a partner, operations lead, risk reviewer, outside IT provider or board member. They need more than a description of the technology. They need to see how the proposed change fits the business.
Before approving a build, look for the following decisions in writing.
The operating problem and intended result
The proposal should name the workflow being changed and why it matters.
Improve efficiency with AI leaves too much open. A clearer statement might describe reducing the preparation required before an experienced reviewer can approve a monthly report, or making missing onboarding information visible before staff follow up with a client.
The intended result should connect to a business priority such as capacity, turnaround, client service, risk, cost or revenue. This gives the firm a reason to measure the project after launch.
The current workflow
The provider should show enough of the current process to demonstrate that the recommendation is grounded in reality.
That includes the starting input, source systems, working documents, handoffs, checks, common exceptions, approvals and final output. It should identify which steps are expected to change and which will remain as they are.
If the current workflow is still uncertain, the proposal should separate discovery from implementation. Leadership should know what will be learned before a final build commitment is made.
The implementation scope and deliverables
The scope should say what the provider will configure, build, connect, document and hand over.
Depending on the use case, deliverables could include an AI assistant, automated workflow, retrieval system, integration, permission structure, testing record, operating instructions and staff training.
Each deliverable should have a practical acceptance condition. AI agent completed is less useful than showing what inputs it must accept, what output it must prepare, which exceptions it must flag and who must be able to operate it.
The proposal should list exclusions and dependencies as clearly as deliverables. This reduces later disagreement over data cleanup, additional systems, content migration or workflows assumed to be included.
The information and access boundary
The proposal should identify the records and systems the implementation needs.
It should explain where information comes from, where it goes, what is retained, which external services are involved and who can access the workflow and its outputs. It should also state which party is responsible for approving access and supplying test material.
Do not send confidential records simply because they would make the demonstration more realistic. Agree how information will be handled before sharing it. Redacted, fictional or limited examples may be enough during early assessment.
Human review and operating responsibility
The proposal should name the decisions that remain with people.
Who checks the sources? Who approves a client-facing output? Who decides what to do when information conflicts? Who may change the workflow after launch?
NIST's AI Risk Management Framework emphasizes defined roles, human oversight and documented responsibility across the system lifecycle. These are practical implementation questions as much as governance questions.
The people operating the workflow should know when the system may proceed, when it must flag uncertainty and how to report a problem.
Testing and acceptance
Testing should cover the workflow the firm will actually use.
The proposal should describe the representative examples, awkward cases and acceptance criteria. It should include incomplete inputs, conflicting information, access restrictions and the absence of the usual reviewer where those situations are relevant.
Measure the human review and correction required. A quick draft may still be uneconomic if the reviewer has to repeat the original task to verify it.
The proposal should say who accepts the implementation and what happens if the criteria are not met. Options may include correction, reduced scope, deferred launch or a decision that the workflow is not ready.
Commercial terms and total expected cost
The firm should be able to distinguish the implementation fee from the continuing cost of operating the workflow.
Look for the price and payment schedule, assumptions that could change the price, recurring model or software fees, expected client time, support and maintenance charges, the cost of later changes and any third-party services purchased directly by the client.
Where the continuing cost cannot be fixed, the provider should explain the unit that drives it and provide a reasonable method for monitoring it.
Timeline and client responsibilities
The timeline should show what the provider needs from the firm and when.
Name the executive sponsor, process owner, reviewers, system contacts and users required for testing. Include access decisions, sample preparation, feedback windows and training.
A delivery date that ignores client decisions and availability is not a complete plan. The proposal should explain which dependencies could move the date.
Support, maintenance and exit
Leadership should know what happens after launch.
The proposal should state who monitors the workflow, handles incidents, updates integrations, responds to vendor changes and maintains instructions. It should identify the support channel and expected response arrangements.
It should also explain what the firm receives if the relationship ends. Relevant items may include administrator access, current documentation, configuration records, code or exportable workflow definitions, subject to the agreed solution and licences.
Financial services firms remain responsible for managing the risks created by relevant third-party arrangements. The FCA's outsourcing and operational resilience guidance emphasizes understanding dependencies, managing risk throughout the arrangement and considering transition and termination. The exact obligations depend on the firm, jurisdiction and use case, but operational continuity belongs in the buying discussion.
The five decisions a proposal should make possible
The work
What workflow will change?
The result
What operating outcome is the firm buying?
The commitment
What must the firm provide during delivery and operation?
The cost
What will this cost to implement, support and run?
The ownership
Who controls, maintains and supports it after launch?
The decision the proposal should make possible
If any important answer still depends on the person who delivered the sales pitch being in the room, return the proposal for clarification.
Halyard uses an AI Opportunity Assessment to examine the workflow, opportunity, information, controls and adoption requirements before implementation is approved. The resulting decision package is designed to make scope, responsibilities and the practical implementation path visible to leadership.
Related Halyard resources
Further reading
Founder of Halyard, an AI implementation company helping financial services firms find and implement practical AI safely.