# Analyze Complex Business Links

> Analyze and structure complex business requirements involving cross-system workflows, multi-document chains, transaction fulfillment, approvals, settlement, inventory, after-sales, or rule-heavy operations. Use when the user needs to clarify a complex business process, abstract document/order models, define state transitions, identify business rules, separate system responsibilities, prepare PRDs, or turn messy stakeholder input into an implementable product design.

- Skill: `huzz-dotcom/analyze-complex-business-links` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add huzz-dotcom/analyze-complex-business-links`
- Raw SKILL.md: https://api.skillmd.com/api/skills/huzz-dotcom/analyze-complex-business-links/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: huzz-dotcom (https://skillmd.com/u/huzz-dotcom)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/huzz-dotcom/analyze-complex-business-links

---


# Analyze Complex Business Links

## Purpose

Use this skill to turn messy complex business requirements into a clear product model. Focus on business abstraction: objects, documents, states, rules, exceptions, and system boundaries.

The core idea:

> A complex business chain is not just a long flow. It is a set of business objects/documents changing state under rule constraints across roles and systems.

## Default Workflow

### 1. Frame the Business Boundary

Start by defining scope before drawing flows or pages.

Answer:

- What business goal does this chain serve?
- What is the start event?
- What is the end condition?
- Who are the actors?
- Which systems participate?
- What is in scope now?
- What is explicitly out of scope?

Output a short boundary statement when the request is ambiguous.

### 2. Run the Main Flow, Then Branches

Describe the happy path first, then add branch and exception paths.

Use this order:

1. Main flow
2. Conditional branches
3. Reverse/exception flow
4. Cross-system failure or compensation

Do not jump directly into UI, fields, or APIs before the chain is clear.

### 3. Abstract Business Objects and Documents

Identify the stable business objects behind the flow. Treat documents/orders as carriers of business facts.

For each object/document, capture:

- Name
- Business meaning
- Source or trigger
- Key fields or dimensions
- Lifecycle/state
- Related upstream and downstream objects
- Responsible system or owner

Common document types:

- Order / order item
- Payment record
- Inventory reservation
- Fulfillment task
- Delivery or verification record
- Receipt/completion record
- After-sales request
- Refund record
- Settlement bill
- Invoice or financial voucher

### 4. Separate State Dimensions

Avoid forcing everything into one coarse status like "processing".

Separate state dimensions when needed:

- Business/order state
- Payment state
- Fulfillment state
- After-sales state
- Settlement state
- Approval state
- Financial/accounting state

For each important state, clarify:

- Meaning
- Entry condition
- Allowed actions
- Exit condition
- Whether it is user-triggered, system-triggered, or external-system-triggered

### 5. Extract Rules From Narrative

Do not leave rules buried in paragraphs. Convert them into a rules table.

Rule categories:

- Eligibility/admission rules
- Validation rules
- Pricing/calculation rules
- Approval rules
- State transition rules
- Fulfillment rules
- Refund/after-sales rules
- Settlement rules
- Exception/compensation rules

Rule table columns:

| Rule | Trigger | Condition | Action | Exception | Owner/System |
| --- | --- | --- | --- | --- | --- |

### 6. Define System Boundaries

For cross-system chains, clarify responsibility explicitly.

Use this table:

| Business object | Created by | Source of truth | Can modify | Consumers | Notes |
| --- | --- | --- | --- | --- | --- |

Key questions:

- Which system owns the data?
- Which system only consumes results?
- Who can change status?
- How are failures retried or compensated?
- What happens if systems disagree?

## Recommended Output Structure

When the user asks for analysis or PRD support, produce the answer in this order:

1. Business boundary
2. Simplified main flow
3. Core objects/documents
4. State dimensions
5. Key rules
6. Exception scenarios
7. System responsibility boundaries
8. Open questions or risks

Keep the first pass lightweight unless the user asks for full detail. Prefer a clear, usable model over an exhaustive enterprise architecture document.

## Transaction Fulfillment Pattern

For familiar transaction fulfillment chains, start from this mental model:

Main flow:

1. User submits order
2. System validates product, price, inventory, promotion, and eligibility
3. Order is created and awaits payment
4. Payment succeeds or fails
5. Inventory is reserved or deducted
6. Fulfillment task is generated
7. Merchant/warehouse/service provider fulfills
8. Delivery, verification, or service completion is recorded
9. After-sales may happen
10. Settlement is generated based on order, payment, fulfillment, and after-sales result

Core objects:

| Object | Meaning |
| --- | --- |
| Order | User transaction agreement |
| Order item | Product-level quantity, price, and allocation |
| Payment record | Payment action and result |
| Inventory reservation | Stock lock or deduction |
| Fulfillment task | Delivery/service execution task |
| Delivery/verification record | Fulfillment process evidence |
| After-sales request | Refund, return, replacement, or compensation |
| Refund record | Reverse fund movement |
| Settlement bill | Merchant/supplier settlement basis |

Useful framing sentence:

> Transaction fulfillment is not one flow. It is a group of documents generated, checked, reversed, and closed under business rules.

## Quality Checklist

Before finalizing an analysis, verify:

- The start and end of the chain are clear.
- Core objects/documents are named.
- Object relationships are visible.
- States are separated by dimension where needed.
- Rules are tabled, not hidden in prose.
- Exception and reverse flows are included.
- System ownership is explicit.
- Remaining ambiguities are listed as questions.

## Anti-Patterns

Avoid:

- Only drawing a process without identifying objects.
- Treating "order status" as the only state dimension.
- Mixing payment, fulfillment, after-sales, and settlement into one status.
- Writing rules as vague prose.
- Designing pages before clarifying the business model.
- Ignoring exceptions such as partial fulfillment, partial refund, retries, reversals, and compensation.
- Leaving system boundaries implicit.