A new workflow, AI agent, CRM process, automation, or integration only creates value when the surrounding way of working is designed too.
That is why Chapman Bright uses ADOPT.
ADOPT is our framework for designing complete solutions across five dimensions: Adoption, Data, Ownership, Process, and Technology.
It helps us avoid a common mistake: treating the implementation of technology as if the solution itself is complete.
Before designing a solution, we first need to understand what should improve and why. At Chapman Bright, we organize improvement opportunities across a broader system:
A client Roadmap may focus on one Pillar or span several connected Pillars, depending on the scope of the engagement. Within that Roadmap, Use Cases describe recognizable improvements worth considering. They focus on the desired improvement, the underlying challenge or opportunity, and the potential value. A Solution Approach then describes a reusable way that improvement could be realized.
The actual client solution comes next. That solution needs to fit the organization that will use and operate it. This is where ADOPT comes in.
What do people need in order to use and sustain the solution?
A technically correct solution can still fail if people do not understand it, trust it, or know how their way of working should change. Adoption considers the human side of the solution.
That can include:
The goal is not simply to launch a solution. The goal is to make it part of how work actually gets done.
What information does the solution require, create, and depend on?
Almost every modern solution depends on data. That data needs to be available, usable, trusted, and governed.
Depending on the solution, this can include:
Data should also support the ability to prove whether the solution created value. A solution that depends on unreliable information will eventually produce unreliable outcomes.
Who is responsible for the solution and the decisions around it?
Solutions need ownership before they go live, not after problems appear. Ownership is broader than naming a system administrator.
It includes:
This becomes especially important with automation and AI. An AI agent may perform an action, but that does not mean the agent owns the business outcome. Automation can execute responsibility. It cannot replace accountability.
How should the work actually happen?
Technology should support a process that makes sense. It should not preserve unnecessary steps simply because those steps existed before the technology was introduced.
Process design considers:
This requires understanding both the official process and the way work really happens in practice. Before automating a process, we should still ask whether every step needs to exist at all. A faster bad process is still a bad process.
What capabilities are required to make the solution work?
Technology comes last. Intentionally. Not because technology is less important, but because the technology should follow from the solution requirements. Only after understanding the Adoption, Data, Ownership, and Process requirements should we determine which technology capabilities are needed.
Those capabilities may include:
Only then should specific platforms, models, connectors, or tools be selected. This helps prevent the capabilities of an existing tool from defining the problem we are trying to solve.
Consider a simple example.
Use Case: Prepare sellers for customer meetings with relevant context.
The desired improvement is clear: sellers should arrive better prepared without spending unnecessary time collecting information manually.
Solution Approach:
A reusable approach could be to automatically gather relevant account, stakeholder, CRM, meeting, relationship, and external information before the meeting and turn it into a concise briefing. That still does not define the complete solution. ADOPT helps complete the design.
Adoption
How will sellers receive and use the briefing? What should change in their preparation process?
Data
Which CRM, meeting, account, stakeholder, and external information is required? How reliable is it?
Ownership
Who owns the briefing process? Who is responsible when information is wrong or incomplete?
Process
When should preparation start? What should be generated? What happens if critical data is missing?
Technology
Which capabilities are required to retrieve information, connect systems, reason over context, generate the briefing, and deliver it?
Only when these dimensions work together does the solution become something an organization can reliably operate.
A recurring problem in transformation work is that solutions are described primarily through technology.
Those statements describe what was built. They do not tell us whether the solution will actually work in the organization. ADOPT shifts the conversation from: What technology should we implement? to: What needs to be true for this improvement to succeed?
Technology is part of that answer. It is not the whole answer.
ADOPT does not replace Chapman Bright’s continuous improvement methodology, Chaploop. They serve different purposes.
Chaploop moves through:
Check → Hypothesise → Align → Perform
Within that cycle, ADOPT can be used repeatedly.
ADOPT therefore complements Chaploop by giving us a consistent lens for what a complete solution needs.
Chaploop™Our frameworks and methods are designed to work together.
Pillars: Where we improve.
Roadmaps: What we prioritize.
Use Cases: What should improve and why.
Solution Approaches: Reusable ways to realize the improvement.
ADOPT: How we design the complete solution.
COSMIC: Additional production design lenses when that solution includes AI agent systems.
Chaploop™: How we continuously diagnose, align, deliver, measure, and improve.
Programs and our Collaboration Model: How Chapman Bright and the client govern that improvement over time.
A solution does not succeed because the technology works.
It succeeds when:
That is ADOPT.
Design the whole solution, not just the technology.