Design review challenges

The AI-generated Blueprint describes a Tour Request that progresses through Create Booking, Finance, Operations, and Completion. The design reflects familiar stakeholder language: the request starts the work, while the Stage names identify activities and teams involved in delivery.

Viewed as a complete Case Design, however, the Blueprint does not yet tell a clear business story. The Case begins with a Tour Request, although the work continues through confirmation, preparation, delivery, and resolution. The proposed Case Type therefore emphasizes the trigger that starts the work rather than the complete business transaction the organization is responsible for managing.

The Stage names create a similar challenge. Create Booking, Finance, and Operations describe activities or ownership rather than meaningful business progress. Stakeholders can see who is involved, although they have less visibility into what has been achieved, what remains, and where attention may be required. The design also makes it harder to distinguish how the booking ultimately concludes, such as successful completion, customer cancellation, weather cancellation, or another recognized outcome. Without those distinctions, performance is harder to interpret and improvement effort is more difficult to target.

Refine the design around a measurable business outcome

Refocusing the Blueprint on Tour Booking creates a clearer frame for the complete solution. It defines the repeatable transaction whose outcome and performance the business needs to understand. The Case Type should represent a recognizable result that can be traced to relevant business measures, such as completed bookings, cancellation outcomes, or end-to-end resolution time.

Milestones such as Booking Requested, Booking Confirmed, Tour Prepared, and Tour Completed provide the information structure for that transaction. They help users understand what has been achieved, what remains, and where Cases may require attention. Processes, Steps, Assignments, and routing then represent the work and responsibility beneath those milestones.

Alternate resolution paths and Case Status complete that information. They allow the business to distinguish, for example:

• Tour Completed, where the intended outcome was delivered
• Customer Canceled, where the customer ended the booking
• Weather Canceled, where operating conditions prevented delivery
• Withdrawn, where the transaction ended for another recognized business reason

Include these distinctions only where they support meaningful communication, action, measurement, or reporting. Use Case Status where it adds timely operational information beyond the Stage, such as work requiring attention or the final disposition of the Case.

The refined design gives the business a clearer way to understand Case volumes, progress, delays, blockages, resolution times, and outcome patterns. These insights can point to opportunities for Process refinement, automation, changes in responsibility, or service-level responses that support earlier intervention.

When refining the Case Design, consider the following questions:

The Tour Booking Workflow contains the major activities described by stakeholders and presents an initial view of how work progresses from booking request through completion. It places plausible Steps within each Stage and represents the principal activities described by stakeholders.

Viewed across the complete Case Life Cycle, however, some work may not yet be in the right place or in the right order. A Step may occur before the information it requires is available, or after its result is needed. Work that could progress independently may have been placed in a fixed sequence. The generated Workflow may also focus on the expected route without representing the important circumstances that change what the Case does.

Some Decision Steps may not yet be associated with the Business Rule that determines their result. A broad label such as Check Weather may describe the activity without making clear what information is evaluated, what decision is being made, which results are possible, or where the Case progresses for each result.

The naming can make the Workflow harder to read as a business explanation. Some Process names describe a department or broad area of work, while some Step names identify a subject rather than the action being performed. Stakeholders may recognize individual words but still be unable to see how the Workflow reflects their business from end to end.

Important variation may also be missing or unclear. Specialist preparation and guardian consent may apply only to selected bookings. Customer changes may need to remain available when required. Payment failure, missing consent, changing weather, rescheduling, or cancellation may require the Case to leave the expected path. If these relationships remain unclear, the Case may reach work before its prerequisites are available, wait unnecessarily, or continue along the expected path when another response is required.

Refine the Workflow around progression and business meaning

Review the Workflow as a business explanation rather than as a sequence of technical elements. Stakeholders should be able to follow how work progresses, understand what causes variation, and explain how the Case reaches each recognized outcome. The Workflow should make that story visible while preserving the business intent needed for implementation.

Trace the Workflow from the beginning of the Case to each recognized outcome. Confirm that each Step is positioned where its required information is available and where its result contributes to progression. Move work where it belongs more naturally within another Process or Stage. Keep Processes sequential only where one genuinely requires the result of another, and allow independent Processes to progress in parallel where they contribute to the same Stage milestone.

Review every Decision Step with its relevant Business Rule. The Rule should state the business logic and possible results clearly, while the Decision Step applies each result to its intended destination. For example, Determine Tour Viability should use Weather Safety Eligibility to decide whether the Case proceeds, waits, reschedules, or cancels.

Use business-facing names that make the Workflow readable from end to end. A Process name should express what its related Steps collectively accomplish, while each Step name should describe the specific user or system action performed. Name the Decision Step for the business determination it applies and associate it with the Business Rule that provides the result. If the Process name and its Steps do not read as one coherent area of work, review the names, grouping, or placement.

Finally, identify the significant situations that are not part of the expected path. Confirm whether each variation represents conditional work, user-initiated behavior, predictable system work, another path within the current milestone, another meaningful Stage, or a recognized resolution. For every variation, make clear what causes the change, what work follows, and where the Case progresses next.

When refining the Workflow, consider the following questions about progression, dependencies, decisions, and variation:

The Workflow uses a combination of user-driven, system-driven, and Agent-driven work. The design identifies several opportunities for automation and Agent participation, although the purpose, controls, and responsibilities associated with that work are not yet fully defined.

Review how user-driven, system-driven, and Agent-driven work operate together across the end-to-end Workflow. Use an Automation Step for a defined system action. Use an Agent-driven Step for a clearly defined business action that requires interpretation, extraction, classification, analysis, synthesis, or drafting.

Confirm that each Agent-driven Step has a clear purpose, the information and permitted actions it needs, and a result that the Workflow can use. The Agent should perform a defined business action rather than own Workflow progression.

Evaluate whether the Agent-driven Step has a clear business purpose, whether the required context is available when the Step begins, and whether the Workflow retains responsibility for validation, exception handling, participant involvement, and continued progression. The Agent contributes a result. The Workflow determines how that result is used.

Before the Step begins, confirm that the required information and authority are available. After the Step completes, confirm that its result meets the requirements of the next Step, Decision, or Workflow path.

Identify where human review, confirmation, or intervention is required because of business risk, ambiguity, authority, or the significance of the result. Make clear what the Case does when the AI Agent cannot complete the action, when its result does not meet the agreed requirements, or when human involvement is required. Every path should lead to a recognized continuation, Stage, or resolution.

Evaluate whether the end-to-end Workflow uses user-driven, system-driven, and Agent-driven work where each creates the greatest value. Confirm that these choices reduce avoidable delay and repeated handoffs, improve accuracy and consistency, and preserve business visibility and control.

Review the end-to-end Workflow

• Is each action represented as user-driven, system-driven, or Agent-driven work according to what the action requires?
• Does each Agent-driven Step have the information it needs and produce a result the Workflow can use?
• Where is human review, confirmation, or intervention required?
• What does the Case do when the AI Agent cannot complete the action or its result does not meet the agreed requirements?

The AI-generated Blueprint routes preparation work to a named tour operator, sends every booking to the branch manager for Approval, and applies the same completion target across the operational Assignments. These choices reflect the people and practices described by stakeholders and provide a reasonable starting point.

Viewed as a complete operating model, however, the Blueprint depends heavily on the current staffing arrangement. Work assigned to one tour operator may wait when that participant is unavailable or already managing other priorities, even when other suitably qualified participants have capacity. The design does not yet show which work genuinely belongs to an individual, which work is shared by a team, or how responsibility continues when availability and workload change.

The same participants also appear to serve several different purposes. The branch manager approves every booking and receives the escalation when work is delayed, but the design does not explain the authority exercised through Approval or whether the manager is the appropriate person to respond to every delay. Assignment ownership, Approval authority, and responsibility for intervention have not yet been considered separately.

The common completion target creates a similar challenge. Preparation activities may look related, but they can protect different business commitments. Delayed equipment preparation, an unresolved safety exception, and a booking awaiting confirmation do not necessarily require the same level of attention or the same business response. If these distinctions remain unclear, workloads can become uneven, routine decisions can wait for unnecessary Approval, and threatened commitments may not become visible early enough for the business to intervene.

Refine the orchestration around responsibility and operational need

Review each user-driven Step to determine the lasting business responsibility it represents. Retain a named participant only where the requirement genuinely depends on that individual. Where suitably qualified participants share responsibility, represent the work as a team responsibility rather than attaching it to the person who performs it today.

Shared work may also create an opportunity to automate allocation using factors such as urgency, priority, participant availability, and required capability. The Blueprint does not need to define the detailed allocation mechanism, but it should capture the business rules the implementation team can use to route work to the right participant.

Treat work ownership, Approval authority, and escalation responsibility as separate decisions. The participant who performs the work may not be the person authorized to approve an exception or the person who should respond when a commitment is at risk.

Use Approval only where the business requires formal authorization or accountable human judgment. Make these points clear:

• What decision requires Approval
• What information the reviewer needs
• Who has the necessary authority
• What Approval causes the Case to do
• What rejection causes the Case to do

For Tour Booking, standard weather and safety criteria can be evaluated through a Business Rule and Decision Step. Branch manager Approval may be appropriate only where an exceptional booking falls outside the agreed criteria and requires authorized judgment.

Review SLAs according to the business commitment being protected. An SLA should make a stated commitment visible and enable an appropriate response. Depending on the business need, that response might increase the priority or visibility of the work, notify an appropriate participant, transfer responsibility, or change how the Case progresses.

When refining Work Orchestration, consider the following questions about responsibility, continuity, authority, and timing:

The proposed Case architecture keeps Guardian Consent as a required Step in every Tour Booking, while Equipment Preparation and Payment are represented as Child Cases. The related work is visible, but the reasons for these different treatments are not yet clear.

Viewed as a complete Case architecture, the design raises important questions. Does Guardian Consent need independent Case management, or should it remain within Tour Booking? When consent is required, does the business need one Guardian Consent Case for the booking or one for each applicable participant? What outcome allows Tour Booking to continue, and how should outstanding or unsuccessful consent affect the Parent?

The other Child Case relationships are equally unclear. The design does not show why Equipment Preparation and Payment require separate outcomes, ownership, timing, or reporting. It is also unclear whether Tour Booking should create and coordinate that work through a Parent-Child relationship or simply obtain information from work managed elsewhere.

The information relationship has not yet been resolved. The design does not show which information can stay fixed when a Child Case is created and which information must keep updating when the Tour Booking changes.

These unanswered questions make it difficult to understand the complete transaction from the Parent Case. They may also result in unnecessary Child Cases, unreliable dependencies, conflicting information, unclear accountability, or the same managed work being created more than once.

Refine the architecture around the Parent outcome

Start with the outcome that Tour Booking remains accountable for delivering. The Parent Case should make the overall Tour Booking easy to understand, even when related work is managed separately because that separate management helps the business.

Review each proposed relationship as part of the complete application design:

• Independence: Does the related work need its own outcome, progression, participants, timing, reporting, or resolution?
• Multiplicity: Does the business need one related Case or several instances, and what determines that number?
• Initiation and coordination: What causes the related work to begin, who or what can initiate it, and what result does Tour Booking depend on?
• Information: What information provides a stable snapshot, and what must remain current as the booking changes?
• Accountability: Does Tour Booking create and coordinate the work, need information from a Case managed elsewhere, or require data about a business entity?
• Duplication: Could another booking, channel, or journey create the same managed work again?

Apply these questions before deciding whether the work belongs within the Parent, requires a Child Case, uses a Case reference, or should remain represented as data.

An AI Agent may identify that related Case work is required and start an authorized Case Type. Review that action as part of the Case architecture: confirm which Case Types the Agent may start, what business condition supports the action, what information the new Case requires, how the Cases are related, and whether human confirmation is required. The Agent initiates the agreed work; it does not determine the Case boundary, relationship, dependency, or outcome independently.

For Guardian Consent, the review may establish that separate Case management creates value because consent has its own participants, timing, outcome, and effect on Parent progression. The resulting design must then clarify whether one consent Case covers the booking or whether each applicable participant requires a separate Case.

For Equipment Preparation, the same review may lead to a different treatment. Preparation that belongs specifically to one Tour Booking may remain within the Parent. Preparation managed once for a shared departure may exist independently, with Tour Booking referencing the readiness information it needs.

The refined architecture should then make the selected relationships explicit: what remains within Tour Booking, what is managed through Child Cases, what is referenced from independently managed Cases, and what belongs in the Case data. It should also show when and how related Cases are initiated, what Tour Booking depends on, how changing information remains aligned, and how repeated work is identified.

Before finalizing the Case architecture, consider the following questions:

An AI-generated Blueprint may show several things that could be improved. Some changes affect the meaning of the whole solution. Others improve only a specific Step, path, responsibility, relationship, or description. Experienced Solution Designers focus first on the decisions that shape the overall design before refining the details that depend on them.

For example, the team may want to refine the name of a Step such as Confirm Equipment. But if the design has not yet decided whether equipment work belongs inside Tour Booking or should be managed as a separate Case, the Step name may change again. Resolve the larger architecture decision first, then refine the Step names, dependencies, routing, and timing that depend on it.

Prioritize refinements across the connected design

Begin with the decisions that provide the frame for the complete solution:

• Business outcome and Case boundary - Confirm the transaction being managed and the measurable result it delivers.
• Case Life Cycle and recognized outcomes - Confirm how stakeholders understand progress, attention needs, and resolution.
• Workflow progression and variation - Confirm where work belongs, what it depends on, what changes the expected path, and where each result leads.
• Workflow efficiency and reliability - Confirm that user-driven, system-driven, and Agent-driven work are used where they create the greatest business value. Confirm that the Workflow provides the required information, Business Rules, Decisions, human review, and exception paths.
• Responsibility, authority, and operational commitments - Confirm who acts, who decides, how responsibility continues, and where intervention protects a genuine commitment.
• Case architecture and relationships - Confirm what remains within the Parent, what requires independent management, how related work is coordinated, and where accountability lies.

Work through this sequence iteratively. Greater clarity in one area may reveal that an earlier decision needs to change. A newly identified Workflow variation may affect the lifecycle. A responsibility or dependency may change where work belongs. A clearer understanding of related work may require the Case boundary to be reconsidered.

Keep reviewing until all major design decisions support the same business outcome. Prioritize refinements by their effect on the complete design, the consequence of carrying the current interpretation forward, and the available business evidence. Retain elements that already serve their purpose.

Use the following questions to prioritize refinements across the connected design:

An AI-generated Blueprint provides a useful first interpretation of the available business information. Experienced Solution Designers review that interpretation as one connected design rather than a collection of isolated elements.

A strong review asks whether the Case Design tells one coherent and measurable business story, whether Workflow progression and variation are explicit and readable, whether user-driven, system-driven, and Agent-driven work improve the end-to-end Workflow within clear controls, whether Work Orchestration supports effective operations and early intervention, and whether the Case architecture keeps the broader outcome clear.

The review is iterative: as understanding develops, each pass may identify changes needed in earlier decisions. Continue until the connected design supports one coherent business outcome and the remaining changes are supported by enough business evidence.