A cycle for selecting, designing, delivering, enabling, and improving automation solutions across people, rules, workflows, agents, integrations, UI automation, and operations.
Guide teams from external customer and capability outcomes to a validated, governed, and operable automation solution.
Method map
Navigate the method
Select a station, cycle, or stakeholder perspective to explore the method.
The automation hypothesis has enough referenced evidence about expected outcome, scope, initial implementation assumptions, critical risks, validation experiment, thresholds, and decision to determine whether it should proceed.
Ownership is clear for the automation opportunity, process decisions, PoC validation, risks, and lifecycle outcomes.
Exit criteria
The selected automation architecture, implementation mechanisms, human controls, security constraints, and recovery approach have been validated with the relevant stakeholders.
The automation has evidence for functional correctness, permissions, exception handling, oversight, monitoring, support, rollback, and operational ownership.
Automation performance, process outcomes, risk signals, manual interventions, incidents, and realized benefits can be monitored and used to prioritize improvements.
Start from the most external meaningful customer. Reuse journey and capability-value evidence to validate whether an automation hypothesis should proceed.
Integration work often jumps too quickly to a technical pattern. This station keeps the team focused on consumer need, value, domain meaning, ownership, reuse potential, viability, assumptions, and validation before selecting APIs, events, files, streams, data products, direct integration, or hybrids.
Clarify the process, experience, domain, service, and non-functional requirements that the later workflow and architecture must satisfy.
The right architecture depends on consumer goals, onboarding expectations, service levels, data quality needs, change tolerance, observability, support, and producer constraints.
Use impact, location, capacity, and earlier requirements to choose the automation implementation approach and record the rationale and remaining risks.
Architecture choices should follow from evidence about business impact, locations, trust boundaries, capacity, latency, data ownership, consistency, operability, security, privacy, governance, and cost.
Design the internal workflow needed to deliver the selected customer and capability outcomes, including work allocation, controls, exceptions, recovery, evidence, and monitoring.
Once the architecture pattern is known, the design must turn capability requirements into clear interface contracts, interactions, schemas, data rules, lifecycle expectations, and consumer obligations.
Build, configure, test, version, deploy, and prepare the operating model for the selected automation path, including ownership, environments, runbooks, monitoring, fallback, rollback, support, and known risks.
A reusable integration capability needs reliable delivery and operations regardless of whether it uses APIs, events, messages, files, streams, data products, connectors, or direct integration.
Use a readiness checklist to review evidence and record the release decision: ready, ready with conditions, remediation required, or not approved.
A formal readiness decision prevents automation solutions from being released without clear evidence, accepted risks, remediation actions, and business and operational ownership.
Activate and roll out the automation safely with communications, training, operating instructions, support paths, adoption monitoring, feedback channels, phased rollout, pause, and rollback conditions.
Automation solutions only create value after rollout when affected people and consuming systems understand what changes, how access and operation work, where to get support, and when rollout should pause, expand, or roll back.
Monitor actual automation outcomes, run success and failure, exceptions, retries, interventions, cycle time, waiting time, cost, errors, unsafe actions, adoption, trust, realized benefit, and which hypothesis assumptions were supported or rejected.
Released solutions need evidence to show whether expected outcomes are being achieved, where manual intervention or recovery is still needed, and what lifecycle decision should be made next.
Publish this cycle
Export the page-specific template after reviewing the entity summary and supporting details above.
Publishing
Markdown and Confluence export
Use Markdown for repositories and static sites, or Confluence-wiki markup for compatible Confluence pages.
Markdown
# Automation Cycle question template
A cycle for selecting, designing, delivering, enabling, and improving automation solutions across people, rules, workflows, agents, integrations, UI automation, and operations.
Use this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.
## 1. Automation Opportunity Strategy
Start from the most external meaningful customer. Reuse journey and capability-value evidence to validate whether an automation hypothesis should proceed.
### Canvas questions
#### Customer Journey Canvas
What journey does the most external meaningful customer experience, and what should improve?
- **Persona**: Who is the typical customer experiencing this journey?
- **Customer Discovers Need**: How does the customer recognize their need or problem?
- **Customer Need Is Resolved**: How is the customer's need ultimately resolved?
- **Journey Steps**: What are the steps the customer takes in their journey?
- **Pains**: What are the customer's pain points or challenges?
- **Gains**: What are the customer's gains or benefits?
- **Inputs & Outputs**: What are the inputs and outputs at each step?
- **Interaction & Processing Rules**: What are the interaction and processing rules at each step?
- **Improvement opportunities**: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?
#### Capability Value Proposition Canvas
Which reusable capability would create value for consumers without deciding yet whether it should be delivered as an API, event, file, stream, data product, or another implementation style?
- **Consumer tasks and outcomes**: What are consumers, partners, users, systems, or teams trying to achieve?
- **Gain-enabling capability features**: What capability features would help consumers achieve better outcomes, speed, automation, insight, reach, or compliance?
- **Pain-relieving capability features**: What capability features would remove friction, manual work, errors, delays, risk, or uncertainty for consumers?
- **Reusable capabilities**: What reusable business or data capabilities could serve these tasks, gains, and pains across more than one consumer or use case?
#### Automation Hypothesis & Validation Canvas
Turn existing journey, value, impact, domain, and capacity evidence into a testable automation decision.
- **Automation hypothesis**: What work do we believe should be automated, and what outcome should it achieve?
- **Reused evidence**: Which earlier canvas outputs support the hypothesis?
- **Critical assumptions**: What could make the hypothesis wrong, unsafe, or unworkable?
- **Validation experiment**: What is the smallest useful test, evidence threshold, and stop condition?
- **Decision**: Proceed, revise, redesign the process, or stop?
### Before this station
- [ ] The automation hypothesis has enough referenced evidence about expected outcome, scope, initial implementation assumptions, critical risks, validation experiment, thresholds, and decision to determine whether it should proceed.
- [ ] Ownership is clear for the automation opportunity, process decisions, PoC validation, risks, and lifecycle outcomes.
### Ready to leave when
- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.
- [ ] Business goals are defined.
- [ ] Market research identifies capability opportunities.
- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.
## 2. Process & Experience Requirements
Clarify the process, experience, domain, service, and non-functional requirements that the later workflow and architecture must satisfy.
### Canvas questions
#### Consumer Experience Requirements Canvas
What experience, operational, and non-functional requirements must the solution satisfy for users, operators, consumers, approvers, and support teams?
- **User, operator, or consumer goals**: What business, workflow, decision, automation, support, or data usage goals must be supported?
- **Availability and timeliness needs**: When must the solution be available, how fresh must information be, and what response, delivery, or completion windows matter to users and operators?
- **Volume and performance expectations**: What user, case, transaction, record, event, file, batch, or work-item volumes must be understood before capacity planning?
- **Data quality and consistency needs**: What accuracy, completeness, consistency, ordering, deduplication, reconciliation, or validation expectations do users, operators, or consuming systems have?
- **Security, privacy, and compliance constraints**: What identity, authorization, confidentiality, residency, consent, retention, audit, or regulatory constraints must the solution satisfy?
- **Activation and access**: How do users, operators, or consuming teams gain access, initiate or participate in the solution, and receive the required permissions and guidance?
- **Change and versioning expectations**: How much change tolerance exists, and what notice, compatibility, migration, training, or versioning expectations apply?
- **Observability and support needs**: What monitoring, status, traceability, quality visibility, support, ownership, and incident communication do users and operators need?
- **Recovery and continuity needs**: What replay, retry, reconciliation, backup, fallback, continuity, or manual recovery expectations must be supported?
- **Constraints for later design**: Which requirements must later architecture, workflow, capacity, integration, or implementation decisions satisfy?
#### Domain Canvas
What are the core entities and business rules related to this capability or domain?
- **Selected Customer Journey Steps**: Which customer journey steps are relevant to this domain?
- **Core Entities & Business Meaning**: What are the core entities and their business meaning?
- **Attributes & Business Importance**: What are the key attributes of each entity and their business importance?
- **Relationships Between Entities**: What are the relationships between the entities?
- **Business, Compliance & Integrity Rules**: What are the business, compliance, and integrity rules related to the entities?
- **Security & Privacy Considerations**: What are the security and privacy considerations related to the entities?
### Before this station
- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.
- [ ] Business goals are defined.
- [ ] Market research identifies capability opportunities.
- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.
### Ready to leave when
- [ ] Capability opportunity is identified and documented.
- [ ] The capability addresses a clear business need and is reusable by its intended consumers.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The capability value proposition has been validated with business and consumer stakeholders.
- [ ] Consumer segments are identified.
- [ ] A high-level implementation roadmap is defined.
## 3. Automation Architecture & Platform Decision
Use impact, location, capacity, and earlier requirements to choose the automation implementation approach and record the rationale and remaining risks.
### Canvas questions
#### Business Impact Canvas
What value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?
- **Expected benefits**: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?
- **Operational efficiency impact**: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?
- **Customer and employee impact**: How will customers, employees, partners, operators, or support teams experience the change?
- **Financial impact**: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?
- **Compliance and strategic impact**: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?
- **Impact of not proceeding**: What happens if the capability, automation, integration, or service is not improved or delivered?
- **Risks and criticality**: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?
- **Mitigations and decision impact**: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?
#### Location Canvas
What geopolitical, regulatory, network, and trust boundaries affect this capability or integration?
- **Location / Trust Groups**: What are the relevant geopolitical, regulatory, network, or trust groups?
- **Group Characteristics**: What are the characteristics of those groups, such as residency, trust level, or network exposure?
- **Relevant Locations / Zones**: What are the relevant locations, zones, or environments within each group?
- **Location / Zone Characteristics**: What are the characteristics of those locations or zones, such as ownership, region, or exposure?
- **Network / Regulatory Distances**: What latency, trust, regulatory, or connectivity distances exist between the locations?
- **Distance Characteristics**: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?
- **Connectivity Endpoints**: What connectivity endpoints or interfaces are associated with the locations?
- **Endpoint Access Characteristics**: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?
#### Capacity Canvas
How much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?
- **Current Business Volumes**: What are the current business volumes and transaction rates?
- **Future Consumption Trends**: What are the anticipated future consumption trends?
- **Peak Load and Availability Requirements**: What are the peak load and availability requirements?
- **Caching Strategies**: What caching strategies can be used to optimize performance?
- **Rate Limiting Strategies**: What rate limiting strategies can be used to manage consumption?
- **Scaling Strategies**: What scaling strategies can be used to accommodate growth?
#### Automation Architecture Decision Canvas
Choose the implementation approach using evidence already gathered.
- **Reused inputs**: Which requirements, capacity, location, impact, and responsibility decisions constrain the choice?
- **Viable options**: Which human, workflow, rule, agent, API, connector, custom, or UI automation options remain viable?
- **Selected approach**: Which implementation style or hybrid is selected?
- **Decision rationale**: Why does the selected approach fit best?
- **Rejected alternatives**: Which serious alternatives were rejected, and why?
- **Open risks**: What still needs validation before delivery or release?
### Before this station
- [ ] Capability opportunity is identified and documented.
- [ ] The capability addresses a clear business need and is reusable by its intended consumers.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The capability value proposition has been validated with business and consumer stakeholders.
- [ ] Consumer segments are identified.
- [ ] A high-level implementation roadmap is defined.
### Ready to leave when
- [ ] The capability addresses a clear business need and is reusable by its intended consumers.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The capability value proposition has been validated with business and consumer stakeholders.
- [ ] Consumer segments are identified.
- [ ] A high-level implementation roadmap is defined.
## 4. Automation Workflow Design
Design the internal workflow needed to deliver the selected customer and capability outcomes, including work allocation, controls, exceptions, recovery, evidence, and monitoring.
### Canvas questions
#### Automation Workflow Canvas
Design the internal workflow needed to deliver the selected customer and capability outcomes.
- **Selected customer and capability outcomes**: Which agreed customer outcomes and capability results must this workflow deliver?
- **Internal workflow steps**: What internal work must happen to produce those outcomes?
- **Work allocation and human control**: What remains human, what is automated, and where are oversight or escalation required?
- **Inputs, outputs, and interactions**: What information, systems, and handoffs are needed?
- **Decisions, exceptions, and recovery**: What changes the flow, what can fail, and how is work recovered?
- **Evidence and monitoring**: What proves correct operation and shows whether the intended outcome was achieved?
### Before this station
- [ ] The capability addresses a clear business need and is reusable by its intended consumers.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The capability value proposition has been validated with business and consumer stakeholders.
- [ ] Consumer segments are identified.
- [ ] A high-level implementation roadmap is defined.
### Ready to leave when
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface design follows agreed design standards and conventions.
## 5. Automation Delivery & Operations
Build, configure, test, version, deploy, and prepare the operating model for the selected automation path, including ownership, environments, runbooks, monitoring, fallback, rollback, support, and known risks.
### Canvas questions
#### Automation Readiness & Operations Canvas
Prepare the minimum operating evidence needed before readiness review.
- **Ownership**: Who owns business outcomes, operations, support, and changes?
- **Environments and access**: Are environments, permissions, credentials, and identities ready?
- **Test evidence**: What proves correct, safe, and reliable behavior?
- **Monitoring and support**: How will health, incidents, users, and operators be supported?
- **Failure and recovery**: How will exceptions, fallback, rollback, and manual recovery work?
- **Readiness status**: Are documentation, risks, conditions, and blocking gaps clear?
### Before this station
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface design follows agreed design standards and conventions.
### Ready to leave when
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface design follows agreed design standards and conventions.
## 6. Automation Readiness Review
Use a readiness checklist to review evidence and record the release decision: ready, ready with conditions, remediation required, or not approved.
### Station questions
- Review the completed design, test evidence, operating model, permissions, credentials, monitoring, support, fallback, and rollback arrangements.
- Verify that known risks, exceptions, unsafe actions, human oversight, compliance requirements, and unresolved assumptions have been addressed or explicitly accepted.
- Record blocking findings, accepted residual risks, release conditions, and required remediation actions.
- Decide whether the release is ready, ready with conditions, requires remediation, or is not approved.
- Record the decision owner, decision date, and evidence used.
- Confirm that nothing proceeds to release without clear business and operational ownership.
- Use readiness evidence to make an explicit go, conditional-go, or no-go decision before production use.
- A formal readiness decision prevents automation solutions from being released without clear evidence, accepted risks, remediation actions, and business and operational ownership.
### Before this station
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The selected interface provides an appropriate abstraction for consumers.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface design follows agreed design standards and conventions.
### Ready to leave when
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.
- [ ] The interface design follows agreed design standards and conventions.
- [ ] The interface contract has been validated and tested against functional and non-functional requirements.
### Other related resources
- **Automation Readiness Checklist**: A checklist for reviewing automation evidence, blocking findings, accepted residual risks, release conditions, remediation actions, decision owner, decision date, and release readiness.
## 7. Automation Rollout & Enablement
Activate and roll out the automation safely with communications, training, operating instructions, support paths, adoption monitoring, feedback channels, phased rollout, pause, and rollback conditions.
### Station questions
- Affected people and changed work: Who will use, operate, support, approve, consume, or be affected by the release, and what responsibilities, decisions, handoffs, or working practices will change?
- Activation and rollout approach: How will access, permissions, pilot use, phased rollout, restricted groups, parallel operation, and rollout expansion be managed?
- Enablement and support: What communication, training, operating instructions, and support paths are required?
- Feedback and control: How will adoption, trust, actual use, issues, and unexpected behavior be monitored, and what conditions trigger pause, rollback, or return to manual operation?
- Plan rollout, enablement, support, feedback, and rollback so released solutions can be adopted safely.
- Automation solutions only create value after rollout when affected people and consuming systems understand what changes, how access and operation work, where to get support, and when rollout should pause, expand, or roll back.
### Before this station
- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.
- [ ] The interface design follows agreed design standards and conventions.
- [ ] The interface contract has been validated and tested against functional and non-functional requirements.
### Ready to leave when
- [ ] The solution passes quality, security, compliance, and readiness checks.
- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.
- [ ] The capability is ready to be published or released through the selected delivery mechanism.
- [ ] Consumer-facing documentation and onboarding materials are ready.
### Other related resources
- **Automation Rollout And Enablement Guide**: Guidance for activating and rolling out automations with changed-work analysis, rollout approach, enablement, support, feedback, adoption monitoring, and control conditions.
## 8. Automation Monitoring & Improvement
Monitor actual automation outcomes, run success and failure, exceptions, retries, interventions, cycle time, waiting time, cost, errors, unsafe actions, adoption, trust, realized benefit, and which hypothesis assumptions were supported or rejected.
### Station questions
- Outcomes and value: Are the expected process, user, and business outcomes being achieved?
- Operational performance: What do successful runs, failures, partial completions, exceptions, retries, timeouts, interventions, processing time, waiting time, and cost show?
- User, risk, and recovery signals: What errors, corrections, unsafe actions, bypassing, mistrust, support needs, fallback events, or recovery failures are occurring?
- Learning and lifecycle decision: Which hypothesis assumptions were supported or rejected, and should the solution be improved, expanded, restricted, redesigned, paused, or retired?
- Use operational, user, risk, and value evidence to decide what to improve, expand, restrict, pause, or retire.
- Released solutions need evidence to show whether expected outcomes are being achieved, where manual intervention or recovery is still needed, and what lifecycle decision should be made next.
### Before this station
- [ ] The solution passes quality, security, compliance, and readiness checks.
- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.
- [ ] The capability is ready to be published or released through the selected delivery mechanism.
- [ ] Consumer-facing documentation and onboarding materials are ready.
### Ready to leave when
- [ ] Consumer-facing documentation and onboarding materials are ready.
- [ ] Consumer onboarding, support, and communication processes are ready.
- [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.
### Other related resources
- **Automation Monitoring and Value Metrics**: Guidance for measuring outcomes, operational performance, user behavior, risk, recovery, realized value, hypothesis learning, and lifecycle decisions after rollout.
Confluence-wiki
h1. Automation Cycle question template
A cycle for selecting, designing, delivering, enabling, and improving automation solutions across people, rules, workflows, agents, integrations, UI automation, and operations.
Use this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.
h2. 1. Automation Opportunity Strategy
Start from the most external meaningful customer. Reuse journey and capability-value evidence to validate whether an automation hypothesis should proceed.
h3. Canvas questions
h4. Customer Journey Canvas
What journey does the most external meaningful customer experience, and what should improve?
* *Persona*: Who is the typical customer experiencing this journey?
* *Customer Discovers Need*: How does the customer recognize their need or problem?
* *Customer Need Is Resolved*: How is the customer's need ultimately resolved?
* *Journey Steps*: What are the steps the customer takes in their journey?
* *Pains*: What are the customer's pain points or challenges?
* *Gains*: What are the customer's gains or benefits?
* *Inputs & Outputs*: What are the inputs and outputs at each step?
* *Interaction & Processing Rules*: What are the interaction and processing rules at each step?
* *Improvement opportunities*: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?
h4. Capability Value Proposition Canvas
Which reusable capability would create value for consumers without deciding yet whether it should be delivered as an API, event, file, stream, data product, or another implementation style?
* *Consumer tasks and outcomes*: What are consumers, partners, users, systems, or teams trying to achieve?
* *Gain-enabling capability features*: What capability features would help consumers achieve better outcomes, speed, automation, insight, reach, or compliance?
* *Pain-relieving capability features*: What capability features would remove friction, manual work, errors, delays, risk, or uncertainty for consumers?
* *Reusable capabilities*: What reusable business or data capabilities could serve these tasks, gains, and pains across more than one consumer or use case?
h4. Automation Hypothesis & Validation Canvas
Turn existing journey, value, impact, domain, and capacity evidence into a testable automation decision.
* *Automation hypothesis*: What work do we believe should be automated, and what outcome should it achieve?
* *Reused evidence*: Which earlier canvas outputs support the hypothesis?
* *Critical assumptions*: What could make the hypothesis wrong, unsafe, or unworkable?
* *Validation experiment*: What is the smallest useful test, evidence threshold, and stop condition?
* *Decision*: Proceed, revise, redesign the process, or stop?
h3. Before this station
* [ ] The automation hypothesis has enough referenced evidence about expected outcome, scope, initial implementation assumptions, critical risks, validation experiment, thresholds, and decision to determine whether it should proceed.
* [ ] Ownership is clear for the automation opportunity, process decisions, PoC validation, risks, and lifecycle outcomes.
h3. Ready to leave when
* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.
* [ ] Business goals are defined.
* [ ] Market research identifies capability opportunities.
* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.
h2. 2. Process & Experience Requirements
Clarify the process, experience, domain, service, and non-functional requirements that the later workflow and architecture must satisfy.
h3. Canvas questions
h4. Consumer Experience Requirements Canvas
What experience, operational, and non-functional requirements must the solution satisfy for users, operators, consumers, approvers, and support teams?
* *User, operator, or consumer goals*: What business, workflow, decision, automation, support, or data usage goals must be supported?
* *Availability and timeliness needs*: When must the solution be available, how fresh must information be, and what response, delivery, or completion windows matter to users and operators?
* *Volume and performance expectations*: What user, case, transaction, record, event, file, batch, or work-item volumes must be understood before capacity planning?
* *Data quality and consistency needs*: What accuracy, completeness, consistency, ordering, deduplication, reconciliation, or validation expectations do users, operators, or consuming systems have?
* *Security, privacy, and compliance constraints*: What identity, authorization, confidentiality, residency, consent, retention, audit, or regulatory constraints must the solution satisfy?
* *Activation and access*: How do users, operators, or consuming teams gain access, initiate or participate in the solution, and receive the required permissions and guidance?
* *Change and versioning expectations*: How much change tolerance exists, and what notice, compatibility, migration, training, or versioning expectations apply?
* *Observability and support needs*: What monitoring, status, traceability, quality visibility, support, ownership, and incident communication do users and operators need?
* *Recovery and continuity needs*: What replay, retry, reconciliation, backup, fallback, continuity, or manual recovery expectations must be supported?
* *Constraints for later design*: Which requirements must later architecture, workflow, capacity, integration, or implementation decisions satisfy?
h4. Domain Canvas
What are the core entities and business rules related to this capability or domain?
* *Selected Customer Journey Steps*: Which customer journey steps are relevant to this domain?
* *Core Entities & Business Meaning*: What are the core entities and their business meaning?
* *Attributes & Business Importance*: What are the key attributes of each entity and their business importance?
* *Relationships Between Entities*: What are the relationships between the entities?
* *Business, Compliance & Integrity Rules*: What are the business, compliance, and integrity rules related to the entities?
* *Security & Privacy Considerations*: What are the security and privacy considerations related to the entities?
h3. Before this station
* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.
* [ ] Business goals are defined.
* [ ] Market research identifies capability opportunities.
* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.
h3. Ready to leave when
* [ ] Capability opportunity is identified and documented.
* [ ] The capability addresses a clear business need and is reusable by its intended consumers.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The capability value proposition has been validated with business and consumer stakeholders.
* [ ] Consumer segments are identified.
* [ ] A high-level implementation roadmap is defined.
h2. 3. Automation Architecture & Platform Decision
Use impact, location, capacity, and earlier requirements to choose the automation implementation approach and record the rationale and remaining risks.
h3. Canvas questions
h4. Business Impact Canvas
What value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?
* *Expected benefits*: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?
* *Operational efficiency impact*: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?
* *Customer and employee impact*: How will customers, employees, partners, operators, or support teams experience the change?
* *Financial impact*: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?
* *Compliance and strategic impact*: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?
* *Impact of not proceeding*: What happens if the capability, automation, integration, or service is not improved or delivered?
* *Risks and criticality*: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?
* *Mitigations and decision impact*: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?
h4. Location Canvas
What geopolitical, regulatory, network, and trust boundaries affect this capability or integration?
* *Location / Trust Groups*: What are the relevant geopolitical, regulatory, network, or trust groups?
* *Group Characteristics*: What are the characteristics of those groups, such as residency, trust level, or network exposure?
* *Relevant Locations / Zones*: What are the relevant locations, zones, or environments within each group?
* *Location / Zone Characteristics*: What are the characteristics of those locations or zones, such as ownership, region, or exposure?
* *Network / Regulatory Distances*: What latency, trust, regulatory, or connectivity distances exist between the locations?
* *Distance Characteristics*: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?
* *Connectivity Endpoints*: What connectivity endpoints or interfaces are associated with the locations?
* *Endpoint Access Characteristics*: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?
h4. Capacity Canvas
How much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?
* *Current Business Volumes*: What are the current business volumes and transaction rates?
* *Future Consumption Trends*: What are the anticipated future consumption trends?
* *Peak Load and Availability Requirements*: What are the peak load and availability requirements?
* *Caching Strategies*: What caching strategies can be used to optimize performance?
* *Rate Limiting Strategies*: What rate limiting strategies can be used to manage consumption?
* *Scaling Strategies*: What scaling strategies can be used to accommodate growth?
h4. Automation Architecture Decision Canvas
Choose the implementation approach using evidence already gathered.
* *Reused inputs*: Which requirements, capacity, location, impact, and responsibility decisions constrain the choice?
* *Viable options*: Which human, workflow, rule, agent, API, connector, custom, or UI automation options remain viable?
* *Selected approach*: Which implementation style or hybrid is selected?
* *Decision rationale*: Why does the selected approach fit best?
* *Rejected alternatives*: Which serious alternatives were rejected, and why?
* *Open risks*: What still needs validation before delivery or release?
h3. Before this station
* [ ] Capability opportunity is identified and documented.
* [ ] The capability addresses a clear business need and is reusable by its intended consumers.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The capability value proposition has been validated with business and consumer stakeholders.
* [ ] Consumer segments are identified.
* [ ] A high-level implementation roadmap is defined.
h3. Ready to leave when
* [ ] The capability addresses a clear business need and is reusable by its intended consumers.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The capability value proposition has been validated with business and consumer stakeholders.
* [ ] Consumer segments are identified.
* [ ] A high-level implementation roadmap is defined.
h2. 4. Automation Workflow Design
Design the internal workflow needed to deliver the selected customer and capability outcomes, including work allocation, controls, exceptions, recovery, evidence, and monitoring.
h3. Canvas questions
h4. Automation Workflow Canvas
Design the internal workflow needed to deliver the selected customer and capability outcomes.
* *Selected customer and capability outcomes*: Which agreed customer outcomes and capability results must this workflow deliver?
* *Internal workflow steps*: What internal work must happen to produce those outcomes?
* *Work allocation and human control*: What remains human, what is automated, and where are oversight or escalation required?
* *Inputs, outputs, and interactions*: What information, systems, and handoffs are needed?
* *Decisions, exceptions, and recovery*: What changes the flow, what can fail, and how is work recovered?
* *Evidence and monitoring*: What proves correct operation and shows whether the intended outcome was achieved?
h3. Before this station
* [ ] The capability addresses a clear business need and is reusable by its intended consumers.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The capability value proposition has been validated with business and consumer stakeholders.
* [ ] Consumer segments are identified.
* [ ] A high-level implementation roadmap is defined.
h3. Ready to leave when
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface design follows agreed design standards and conventions.
h2. 5. Automation Delivery & Operations
Build, configure, test, version, deploy, and prepare the operating model for the selected automation path, including ownership, environments, runbooks, monitoring, fallback, rollback, support, and known risks.
h3. Canvas questions
h4. Automation Readiness & Operations Canvas
Prepare the minimum operating evidence needed before readiness review.
* *Ownership*: Who owns business outcomes, operations, support, and changes?
* *Environments and access*: Are environments, permissions, credentials, and identities ready?
* *Test evidence*: What proves correct, safe, and reliable behavior?
* *Monitoring and support*: How will health, incidents, users, and operators be supported?
* *Failure and recovery*: How will exceptions, fallback, rollback, and manual recovery work?
* *Readiness status*: Are documentation, risks, conditions, and blocking gaps clear?
h3. Before this station
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface design follows agreed design standards and conventions.
h3. Ready to leave when
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface design follows agreed design standards and conventions.
h2. 6. Automation Readiness Review
Use a readiness checklist to review evidence and record the release decision: ready, ready with conditions, remediation required, or not approved.
h3. Station questions
* Review the completed design, test evidence, operating model, permissions, credentials, monitoring, support, fallback, and rollback arrangements.
* Verify that known risks, exceptions, unsafe actions, human oversight, compliance requirements, and unresolved assumptions have been addressed or explicitly accepted.
* Record blocking findings, accepted residual risks, release conditions, and required remediation actions.
* Decide whether the release is ready, ready with conditions, requires remediation, or is not approved.
* Record the decision owner, decision date, and evidence used.
* Confirm that nothing proceeds to release without clear business and operational ownership.
* Use readiness evidence to make an explicit go, conditional-go, or no-go decision before production use.
* A formal readiness decision prevents automation solutions from being released without clear evidence, accepted risks, remediation actions, and business and operational ownership.
h3. Before this station
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The selected interface provides an appropriate abstraction for consumers.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface design follows agreed design standards and conventions.
h3. Ready to leave when
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.
* [ ] The interface design follows agreed design standards and conventions.
* [ ] The interface contract has been validated and tested against functional and non-functional requirements.
h3. Other related resources
* *Automation Readiness Checklist*: A checklist for reviewing automation evidence, blocking findings, accepted residual risks, release conditions, remediation actions, decision owner, decision date, and release readiness.
h2. 7. Automation Rollout & Enablement
Activate and roll out the automation safely with communications, training, operating instructions, support paths, adoption monitoring, feedback channels, phased rollout, pause, and rollback conditions.
h3. Station questions
* Affected people and changed work: Who will use, operate, support, approve, consume, or be affected by the release, and what responsibilities, decisions, handoffs, or working practices will change?
* Activation and rollout approach: How will access, permissions, pilot use, phased rollout, restricted groups, parallel operation, and rollout expansion be managed?
* Enablement and support: What communication, training, operating instructions, and support paths are required?
* Feedback and control: How will adoption, trust, actual use, issues, and unexpected behavior be monitored, and what conditions trigger pause, rollback, or return to manual operation?
* Plan rollout, enablement, support, feedback, and rollback so released solutions can be adopted safely.
* Automation solutions only create value after rollout when affected people and consuming systems understand what changes, how access and operation work, where to get support, and when rollout should pause, expand, or roll back.
h3. Before this station
* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.
* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.
* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.
* [ ] The interface design follows agreed design standards and conventions.
* [ ] The interface contract has been validated and tested against functional and non-functional requirements.
h3. Ready to leave when
* [ ] The solution passes quality, security, compliance, and readiness checks.
* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.
* [ ] The capability is ready to be published or released through the selected delivery mechanism.
* [ ] Consumer-facing documentation and onboarding materials are ready.
h3. Other related resources
* *Automation Rollout And Enablement Guide*: Guidance for activating and rolling out automations with changed-work analysis, rollout approach, enablement, support, feedback, adoption monitoring, and control conditions.
h2. 8. Automation Monitoring & Improvement
Monitor actual automation outcomes, run success and failure, exceptions, retries, interventions, cycle time, waiting time, cost, errors, unsafe actions, adoption, trust, realized benefit, and which hypothesis assumptions were supported or rejected.
h3. Station questions
* Outcomes and value: Are the expected process, user, and business outcomes being achieved?
* Operational performance: What do successful runs, failures, partial completions, exceptions, retries, timeouts, interventions, processing time, waiting time, and cost show?
* User, risk, and recovery signals: What errors, corrections, unsafe actions, bypassing, mistrust, support needs, fallback events, or recovery failures are occurring?
* Learning and lifecycle decision: Which hypothesis assumptions were supported or rejected, and should the solution be improved, expanded, restricted, redesigned, paused, or retired?
* Use operational, user, risk, and value evidence to decide what to improve, expand, restrict, pause, or retire.
* Released solutions need evidence to show whether expected outcomes are being achieved, where manual intervention or recovery is still needed, and what lifecycle decision should be made next.
h3. Before this station
* [ ] The solution passes quality, security, compliance, and readiness checks.
* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.
* [ ] The capability is ready to be published or released through the selected delivery mechanism.
* [ ] Consumer-facing documentation and onboarding materials are ready.
h3. Ready to leave when
* [ ] Consumer-facing documentation and onboarding materials are ready.
* [ ] Consumer onboarding, support, and communication processes are ready.
* [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.
h3. Other related resources
* *Automation Monitoring and Value Metrics*: Guidance for measuring outcomes, operational performance, user behavior, risk, recovery, realized value, hypothesis learning, and lifecycle decisions after rollout.