Built Into Work · HR Tech field guide
Find the pain.
Redesign the work.
Put it to work.
A practical guide to a workflow-transformation offsite.
Use a focused day to turn a difficult workflow into a shared design, resolved decisions and an owned implementation plan. The result might be a simpler process, a configuration change, a purchased capability or a custom build. AI is one possible part of the answer.
The output: one bounded workflow, a clear outcome, a tested future-state design, and a named owner for the next implementation step.
What this guide includes
- Prepare the work and protect the capacity.
- Facilitate a one-day offsite.
- Map value and requirements.
- Simulate the redesigned workflow.
- Commit to a 30-day implementation plan.
Built from Vic Akosile’s HR Tech keynote: The Architecture of AI Adoption. The agenda and worksheets translate the talk’s method into a reusable facilitation guide. Timings and checkpoints are suggested starting points, not a guarantee of delivery.
01 / Before the offsite
Find the pain. Make room to act.
Choose a workflow with a boundary
Start with a trigger and an observable outcome: “accepted offer → employee ready for day one” is more useful than “fix onboarding.” Narrow it further if the owners cannot influence the full journey.
- Listen to both sides. Interview people doing the work and people receiving it. Ask for a recent normal case and a case that went wrong.
- Bring evidence. Collect anonymized examples of waiting, re-entry, missing information, corrections and exceptions. Separate measured facts from assumptions.
- Name the outcome owner. Include a person who can make decisions about the process, plus the people who understand its handoffs.
- Bring delivery and control expertise. Invite technical support and relevant data, security, policy or legal owners where the workflow needs them. Use a facilitator and a decision recorder.
- Protect implementation time. Agree what existing work will stop, what coverage is needed, or which delivery capacity will be added. Reserve time after the offsite.
Readiness gate: if there is no decision owner, no access to evidence, or no follow-through capacity, use the session for discovery and resolve those gaps before promising implementation.
02 / Suggested one-day agenda
Redesign backward from the outcome.
| Time | Work together | Leave with |
|---|
| 09:00–09:30 | Agree on the outcome, boundary and evidence. | Definition of done and baseline. |
| 09:30–10:15 | Walk through a recent case. Mark waits, handoffs and rework. | A current-state map with facts and assumptions distinguished. |
| 10:15–10:30 | Break. | |
| 10:30–11:30 | Ask what actually has to be true. Separate requirements, deliberate experience choices and inherited habits. | Requirements and decisions to challenge. |
| 11:30–12:15 | Design backward from the desired outcome. | A first future-state map. |
| 12:15–13:00 | Lunch. | |
| 13:00–14:00 | Simulate a normal case, missing information, a changed decision and an exception. | Failure points, revised handoffs and owners. |
| 14:00–14:45 | Choose the first improvement and delivery model. | Bounded scope, dependencies and operating owner. |
| 14:45–15:00 | Break. | |
| 15:00–16:00 | Agree tests, evidence, approvals and implementation capacity. | A 30-day plan with names and dates. |
| 16:00–16:30 | Read back decisions. Resolve ownership. Book the review. | An explicit commitment or a clear blocked decision. |
Facilitator prompts
“What outcome does this step protect?” “What would break if we removed it?” “Is this a requirement, an intentional choice, or a habit?” “Who decides?” “When someone says ‘then somebody checks it,’ who checks what, and how do they know it is their turn?”
03 / Working template
Define value and what must be true.
Use the seven value dimensions: efficiency, scale, quality, experience, risk, capability and financial impact. Do not treat hours saved as cash savings unless the capacity is actually redeployed or costs change.
04 / Working template
Make the future workflow testable.
For each step, specify the input, action, owner, output and exception. Draw the map on a shared board or repeat the row below.
| Trigger / input | Action / decision | Owner | Output / handoff | Exception / escalation |
|---|
|
Where can the four A’s help?
Assistants support a person. Applications provide a purpose-built interface. Automations execute defined steps. Agents can pursue tasks within explicit boundaries. Name the human owner, permitted actions and escalation path for each.
| Scenario | What to test |
|---|
| Normal case | Does every handoff reach a named owner? Is completion visible? |
| Missing information | Who requests it? Can the case safely pause? Who sees the delay? |
| Changed decision | Which downstream steps must stop or be updated? Who confirms the change? |
| Exception or failure | Who takes over? What is the fallback? What evidence is retained? |