What Did Go-Live Actually Prove?
Exploring this for your team? Talk to CrmWare →
What a go-live acceptance actually proves
What did the last programme you signed off actually establish?
A conventional solution acceptance commonly establishes five things: the requirements were delivered, the system is secure, the integrations work, the platform is available, and the users have been prepared. Call that solution acceptance. It is a real achievement, worth certifying.
What it does not establish is whether the organisation gained a measurable operational advantage — or built the capability to sustain it. Faster, cheaper, more reliable, less error-prone: none of that is in scope at the moment of signature.
This is not a new observation, and it would be dishonest to present it as one. UK government guidance on major projects has held since 2017 that success should be measured not only by delivery to time, cost and quality, but by positive, measurable improvements for stakeholders.[1] That guidance sits inside an established benefits-management discipline built around exactly this gap.
When the system acts, the gap stops waiting
In a conventional programme, an unproven benefit could remain a deferred measurement problem. An agentic system changes the exposure: it continues interpreting context, taking actions and routing exceptions while that result remains unproven.
The interval nobody accepted is therefore not idle. It is producing consequences throughout.
Public authorities have reached the same operating conclusion from different directions and for different reasons. A national audit institution, a national industry department, and binding European law each conclude that evaluation cannot stop at deployment: the US Government Accountability Office holds that entities should continuously monitor and evaluate the system to ensure it addresses programme objectives;[2] Canadian federal guidance, which is voluntary, tells managers to establish ongoing monitoring and evaluation procedures for deployed systems;[3] and under the EU AI Act, deployers must monitor operation and suspend use when the system may present a risk.[4] None of them is a vendor. The convergence is the point, not any one of them.
Separately, and at much lower evidential weight, the platform's own account agrees: Salesforce describes an Agentforce lifecycle whose five phases end in monitoring and tuning.[5] That establishes what Salesforce says its lifecycle is — not independent evidence, and no validation of any outcome.
The unit that second acceptance should be written against is, we have argued, the governed workflow rather than the platform implementation.
The two acceptances a sponsor must define
From here on this is CrmWare's operating synthesis. No source establishes the structure below; it is a recommendation, offered the same way we offered the seven-element workflow definition.
The remedy is not only more pre-go-live testing. Testing improves solution acceptance, which is already the part that works. What is missing is a second acceptance, defined separately, with its own evidence and its own owner.
Outcome acceptance needs five things fixed before approval: the baseline the work starts from; the measurable result that would justify the investment; the observation period over which it is judged; the evidence owner who reports it; and the decision to be taken if the result does not materialise.
That last item is the one most often missing, and it makes the other four honest. A measure with no consequence attached is a report, not an acceptance.
The observation period can show whether the advantage persists. It does not, by itself, prove that the organisation owns the capability to operate, govern and evolve what produced it; that remains a separate ownership decision.
The available research is consistent with this being worth doing, without proving it. MIT CISR's survey work found that adapted workflows, together with redefined roles and metrics and the level of use, were statistically significant across multiple value measures.[6] That is an association in a member-funded study with no published effect size, so it supports attention to how work and measurement are redesigned. It does not establish that defining acceptance criteria causes better outcomes, and we are not claiming it does.
The decision before you approve
Turn this into one question, asked before the programme is funded rather than after it disappoints.
Ask what will have been proven on the day you accept. If the answer describes requirements, stability and training, you have one acceptance and you are buying the other on trust.
A thin answer is not a documentation problem to be fixed later by writing more of the plan down. It is a scoping problem, and the response is to narrow the programme until both acceptances can honestly be defined for what remains — not to widen it until the promise sounds large enough to justify the budget.
This is a different question from whether the arrangement leaves you in control; if that is the decision in front of you, score the deal itself before you sign.
What will actually have been proven when we accept this programme?
References
[1] UK Infrastructure and Projects Authority and Cabinet Office. Guide for Effective Benefits Management in Major Projects. 2017. https://assets.publishing.service.gov.uk/media/5a8210e1e5274a2e87dc0f71/Guide_for_Effective_Benefits_Management_in_Major_Projects.pdf
[2] US Government Accountability Office. Artificial Intelligence: An Accountability Framework for Federal Agencies and Other Entities. 2021. https://www.gao.gov/assets/gao-21-519sp.pdf
[3] Innovation, Science and Economic Development Canada. Implementation guide for managers of artificial intelligence systems. 2025. https://ised-isde.canada.ca/site/ised/en/implementation-guide-managers-artificial-intelligence-systems
[4] European Union. Regulation (EU) 2024/1689, Article 26: Obligations of deployers of high-risk AI systems. 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
[5] Salesforce. Exploring the Agentforce Development Lifecycle. 2025. https://www.salesforce.com/blog/exploring-the-agentforce-development-lifecycle
[6] MIT Center for Information Systems Research. Leveraging Digital Colleagues for Enterprise Value. 2026. https://cisr.mit.edu/publication/2026_0401_DigitalColleagues_WeillWoerner