Use this worksheet to think through one business process or workflow you want to observe. You do not need all the answers right now — start with what you know, and Outcome Owl will help you discover what you did not expect.
Fill out one worksheet per process. If you have multiple processes, start with the one that causes the most pain or costs the most when it goes wrong.
Before You Start
Why This Process?
Before mapping steps and systems, articulate why this process matters and where it hurts today. These answers guide every decision that follows — which steps to observe, what rules to set, how severe to rate them, and who needs to know when something goes wrong.
What prompted this?
Where does it break today?
Every process has pain points — steps where things get stuck, exceptions that require manual intervention, or handoffs where work disappears. These are the areas Outcome Owl is designed to illuminate.
How critical is this process?
Understanding business impact helps you assign meaningful severity levels and set the right Impact Areas on each process step. Check all that apply — most processes touch more than one.
regulatory requirements, audit obligations, legal exposure
service quality, responsiveness, satisfaction
revenue, cost, margin, cash flow
throughput, efficiency, resource utilization
brand perception, public trust, partner confidence
direct revenue impact, lost sales, delayed billing
data protection, access control, fraud exposure
These seven areas correspond directly to the Impact Area flags you will set on each process step in Outcome Owl.
Who needs to know?
Section 1
Name Your Process
What do your people call this process today? Use the vocabulary your organization already uses — not a system name or a technical label.
Section 2
The Starting Step
Every process begins somewhere. This is the event that kicks things off.
Attributes worth capturing at this step
List any data fields that travel with this event and might be useful for analysis later. Think about: who, what, where, how much, which type.
| Attribute | Example Value | Why It Might Matter |
|---|---|---|
Examples: customer_type = "Enterprise", region = "Southeast", submitted_amount = 4500.00, channel = "Web Portal", priority = "Expedited"
Common pitfalls with identifiers
- Do not use the entity ID alone when the entity passes through multiple steps. A Claim Number identifies the claim, but you will have multiple observations for that claim (Received, Reviewed, Paid). Include the step in the ID to avoid collisions.
- Do not use a timestamp as an identifier. Timestamps collide when two events happen in the same second, carry no semantic value, and break when system clocks drift.
- Do not use a display string that users can edit. If a customer-facing label changes ("Case #4421" becomes "Escalated Case #4421"), the audit trail breaks — Outcome Owl matches the original ID, not the new one.
Section 3
The Ending Step(s)
Most processes have at least one "good" ending and often a "bad" ending too.
Positive ending (the happy path)
Negative ending (the unhappy path)
Not every process ends well. Some are denied, cancelled, abandoned, or escalated. These endings are just as important to observe.
Attributes worth capturing at ending steps
| Attribute | Example Value | Why It Might Matter |
|---|---|---|
Examples: paid_amount = 3200.00, denial_reason = "Incomplete Documentation", delivery_carrier = "Regional Express", resolution_type = "Refund"
Section 4
The Steps In Between
Most processes have intermediate steps. You do not need to capture every micro-step. Focus on the ones where handoffs happen, decisions are made, time passes and you want to know how much, or problems tend to occur. It is fine if this list is incomplete — you can add more later.
| Step Name | Which System? | Can You Collect It? | Duration or Point-in-Time? | Links Back To |
|---|---|---|---|---|
Examples: Eligibility Check · Claims Platform · Yes, API event · Duration (30 min avg) · Claim Received | Underwriting Review · Loan Origination System · Yes, nightly CSV · Duration (1–3 days) · Credit Check | Quality Inspection · Warehouse System · Yes, scan event · Point-in-time · Order Packed
Steps that happen sometimes but not always
Some steps only occur under certain conditions (e.g., "Manager Approval" only for orders above $5,000, or "Appeals Process" only for denied claims). These are valuable to track — they reveal the exception paths.
| Conditional Step | When Does It Happen? |
|---|---|
Attributes worth capturing at intermediate steps
Different steps may carry different attributes. A shipping step has carrier and tracking information; a review step has reviewer and decision.
| Step Name | Attribute | Example Value |
|---|---|---|
Section 5
Linkage — How Steps Connect
Outcome Owl links steps into an end-to-end process chain using identifiers your systems already produce. The simplest approach: every step carries the same unique identifier (the "golden thread").
Do not worry if the linkage is imperfect. Outcome Owl handles out-of-order arrival, delayed events, and even cases where a child event arrives before its parent. The platform links them retroactively.
Which identifier pattern fits your process?
Pattern A — Natural Golden Thread
All systems reference the same business identifier (e.g., every step carries the same Claim Number). Observation IDs include the golden thread (CLAIM-91823-RECEIVED, CLAIM-91823-PAID), so search and troubleshooting are intuitive, linkage is strong, and entity-level analytics can use the golden thread directly.
Pattern B — System-Scoped IDs with a Linking Key
Each system mints its own identifier, but a shared reference exists somewhere (a field or a lookup table). Prefix IDs with the source system (ERP-44210, WMS-PKT-8891); the linking key travels as an attribute. Linkage requires mapping — the parentid on one observation must reference the other's ID. Attributes become the key to cross-process analysis.
Pattern C — No Shared Key
Systems are decoupled — no natural business identifier appears everywhere. IDs are fully system-scoped (CRM-CASE-4421, ERP-ADJ-11029). Linkage relies on explicit parentid assignment at integration time (the most error-prone pattern). Start with permissive guardrails and tighten as linkage stabilizes; over time, Outcome Owl's own process chain becomes the linking mechanism you did not have before.
parentid when integrating?Why this matters long-term: the identifier strategy you choose today propagates through every analytics capability — search, Process Explorer, Audit Trail Explorer, entity-level analytics, and deep-linking. Getting identifiers and guardrails right during setup pays compounding returns.
Section 6
What Does Good Look Like?
Before setting up rules, think about what "normal" means for this process. These become your first deviation and threshold rules.
Time-based expectations (Deviation Rules)
"If step A happens, step B should follow within X days."
| After This Step… | …This Step Should Follow | Within How Long? | How Serious If It Doesn't? (1–5) |
|---|---|---|---|
Examples: After "Claim Received," "Eligibility Check" should follow within 2 days (severity 3) · After "Order Shipped," "Order Delivered" should follow within 14 days (severity 3) · After "Application Submitted," "Identity Verification" should follow within 1 day (severity 4)
Numeric boundaries (Threshold Rules)
"Flag when a value exceeds or falls below a boundary."
| On This Step… | Check This Value… | Flag When… | How Serious? (1–5) |
|---|---|---|---|
Examples: On "Payment Processing," flag when amount > $10,000 (severity 4) · On "Refund Issued," flag when total refunds > $50,000 across all (severity 5) · On "Flight Completed," flag when delay_minutes > 120 (severity 3)
Things that should not happen
Some deviation rules detect unwanted events: "If step A happens, step B should NOT follow."
| After This Step… | …This Step Should NOT Happen | Within How Long? | How Serious? (1–5) |
|---|---|---|---|
Examples: After "Booking Confirmed," "Flight Cancelled" should not follow within 30 days (severity 4) · After "Invoice Approved," "Invoice Rejected" should not follow within 7 days (severity 4)
How your identifier pattern (Section 5) affects rules
- Pattern A (golden thread): Rules are highly reliable because parent-child linkage is clean. Start with time-based expectations and trust the results immediately.
- Pattern B (linking key): Rules work well, but verify that parent mappings are correct before interpreting deviation results. A "missing step" deviation might mean the step did not happen, or that the mapping broke.
- Pattern C (no shared key): Start with broad rules and loose thresholds. Tighten them as your integration matures and linkage errors decrease.
Section 7
Process or Audit Trail?
Most workflows are Processes — steps happen in a defined sequence with measurable duration between them. Some are Audit Trails — standalone events tied to a long-lived entity (an asset, an employee, a contract) where the sequence is fluid, events span months or years, and duration between events is not the point.
Section 8
Data Sources Summary
Summarize where the data will come from. This helps plan the technical integration.
| Step(s) | Source System | Export Method CSV / API / Kafka / Manual | Frequency | Format |
|---|---|---|---|---|
Section 9
Quick Sketch
Draw a simple left-to-right flow of your process. Boxes for steps, arrows for connections. Mark the starting step, the ending step(s), and any branches. This does not need to be perfect — it is a conversation starter.