The final presentation is a handover point, not the end of the work. A prototype may show an idea worth investigating; a workshop may establish priorities. Neither creates an internal owner or an approved deployment plan automatically. Agree the follow-up before the event if you want the output to have somewhere to go.
Capture the output on day zero
Record what was produced, who contributed, what inputs and tools were used, what was tested and what remains unknown. For a workshop, keep the decision record and reasons for deferred ideas. For a practical challenge, keep the evaluation alongside the demonstrator rather than only the polished demo.
Assign a sponsor who can make the next decision and an owner who can run the investigation. Name a reviewer for output quality and involve the relevant internal specialists before changing access or scope.
A sample thirty-day plan
These weeks are a planning sequence, not a promise that a project can be approved or deployed in thirty days. Some dependencies will take longer.
| Period | Work | Owner | Gate / output |
|---|---|---|---|
| Days 1–5 | Confirm objective, output, tool access, permitted data and ownership | Business owner with internal specialists | Written scope; unresolved permissions block testing |
| Days 6–10 | Define baseline, test materials, quality criteria and stop conditions | Experiment lead and reviewer | Comparable evaluation plan |
| Days 11–20 | Run a bounded test with agreed inputs and human review | Experiment team | Observations, failures, total effort and limitations |
| Days 21–25 | Compare results and discuss dependencies | Business owner and sponsor | Evidence record and options |
| Days 26–30 | Decide to continue, change, pause or stop | Decision owner | Next scope, owner and review date, or documented closure |
If there is no permission to use actual business data, start with synthetic or specifically approved material. Do not bypass that gate to meet the sample calendar.
Measure different outcomes separately
| Outcome | Question | Example evidence | What it does not prove |
|---|---|---|---|
| Participation | Who attended or completed an activity? | Counts with a stated denominator | Learning or sustained use |
| Satisfaction | Did participants find it useful? | Feedback with response rate | Business impact |
| Learning | Can people perform the defined task? | Assessed exercise and review rubric | Use on real work over time |
| Continued use | Is the approved workflow still used? | Follow-up checks with non-responses recorded | That the event caused the change |
| Experiment value | Does the approach improve the chosen task? | Quality and total-effort comparison | Production readiness or general ROI |
Choose measures that fit the original question. Include human review, corrections and coordination when assessing effort. Document whether a figure is observed, estimated or self-reported.
If several prototypes were presented, keep all of them in the follow-up register: continued, changed, paused, stopped and not reviewed. Reporting only the successful examples hides the denominator.
Use a simple experiment record
For every candidate, write:
The use-case worksheet provides the starting record. Keep changes to that scope visible as the experiment develops.
Decide what happens next
Continue when the evidence supports another bounded step and an owner can resource it. Change the scope when the underlying problem is useful but the selected approach fails. Pause when a necessary permission or dependency is missing. Stop when the value or feasibility case does not hold.
A production project may need security, privacy, integration, monitoring and operational decisions beyond this template. Hand those questions to the appropriate owners. A technical deployment is a separate undertaking from a workshop or demo.
If the barrier is skills, plan practice and feedback on the actual role. If the barrier is disagreement, use a decision-focused session. The enterprise guide helps distinguish those needs.
Include follow-up in the original brief
Before commissioning the programme, agree who receives materials, who owns participant outputs, whether a review session is included and when provider support ends. The RFP checklist and cost framework make that scope explicit.
Methodology
About this plan
AISB editorial follow-up template, published on 4 October 2026. The sequence is illustrative, not a client cohort study. No continuation rate, productivity result, causal impact or production-readiness guarantee is asserted.
Include handover in your programme scope
Describe what the session should produce and who will own the work afterwards.
Frequently asked questions
What should happen after an AI hackathon?
Capture the demonstrator and its limitations, assign a business owner, confirm data and tool permissions, and define the next test. Any wider use needs a separate approval process; demo day does not authorise production deployment.
How do we measure an AI workshop's impact?
Separate participation, satisfaction, demonstrated learning, continued use and business outcomes. For an experiment, compare quality and total effort with a stated baseline and include review and rework. Avoid claiming causality from a single event.
What if an experiment does not continue?
Record the reason: insufficient value, missing permission, technical limits, lack of ownership or another dependency. A documented stop decision can be a useful outcome and should not disappear from follow-up reporting.
Published by
- AI Summit BarcelonaEditorial team
Related reading
AI Use-Case Discovery: Agenda and Prioritisation Template
Start from a task rather than a tool. Record the baseline, permitted inputs, expected output and owner; then use evidence and unresolved dependencies to decide what to test.
Enterprise AI Adoption: From Awareness to Useful Experiments
A decision guide for companies moving beyond AI awareness. Diagnose the barrier, choose the appropriate format and define the evidence needed before expanding an experiment.
Choosing a Corporate AI Programme Provider: Checklist and RFP
A provider checklist and reusable brief for workshops, briefings, events and practical AI programmes. Ask for evidence, separate responsibilities and make exclusions explicit.