Agencies feed PII-free sold-flight data; SkyCop detects disrupted, claimable flights; a human agent converts the passenger into a signed claim. This is the working model, the customer journeys, how each role operates, and where the real risk sits.
The pipeline is fully automated up to the Flight lead. From there, everything depends on a human agent.
flowchart TD
A["Agency exports sold flights
Amadeus Agency Insight → XLSX"] -->|"daily automated email"| B["SB1 · Flight-feed ingestion"]
B --> C{"Validate · normalize
dedup · idempotent"}
C -->|"errors"| C1["Import error log
NO PII"]
C -->|"ok"| D["Sold flight records
flight data only"]
D --> E["SB3 · Disruption detection
at / after scheduled departure"]
E --> F{"OAG: cancelled
or delayed 3h+?"}
F -->|"no"| Z["No side effects
no lead · no email · no report"]
F -->|"yes"| G["SB2 · Scoring API wrapper
wraps existing model R1"]
G --> H{"Score ≥ claimable threshold?"}
H -->|"no"| Z
H -->|"yes"| I["FLIGHT LEAD created · SB4"]
I --> J{"Agent id present
in feed?"}
J -->|"yes"| K["Assigned → Incoming
agent emailed"]
J -->|"no"| L["Unassigned
Owner / Admin emailed"]
L -->|"Owner/Admin assigns"| K
K --> M["Agent works the lead →"]
style I fill:#2ee6b6,stroke:#1aa,color:#06231c
style Z fill:#e9edf5,stroke:#bbb,color:#555
style L fill:#ffe1b0,stroke:#e0a050,color:#5a3b00
Claimable statuses: 01_green, 02_yellow, 03_obscure, 04_orange_light always; 04_orange only in good jurisdictions (UK, AT, FR, ES, RO, SE).
flowchart TD
M["Agent opens Flight lead"] --> N["Reverse-lookup passengers
in AGENCY system — manual, off-platform"]
N --> O{"Matching
passengers?"}
O -->|"no"| P["Mark 'No matching passengers'
+ reason + note"]
O -->|"yes"| Q["Create one or more Claims
enter passenger PII"]
Q --> R["Close Flight lead
→ work moves to Claims"]
R --> S["Contact passenger by phone / WhatsApp
the live SALES step"]
S --> T["Generate secure form link
+ Send templated email"]
T --> U["Passenger: edit · upload docs · sign · submit"]
U -->|"submitted"| V["Claim → Passenger submitted
Reward accrual PER passenger"]
U -->|"refuses / already claimed"| W["Mark 'Passenger declined'
+ reason"]
V --> X["Monthly payout batch
→ manual pay → Reward paid"]
style S fill:#3da9fc,stroke:#1577c4,color:#021426
style V fill:#2ee6b6,stroke:#1aa,color:#06231c
style N fill:#ffe1b0,stroke:#e0a050,color:#5a3b00
The two amber boxes are the bottlenecks: the off-platform reverse-lookup (R1) and the live sales call (the actual conversion engine).
A Flight lead exists only before claim work; the moment claims are created, it closes and all work moves to Claims — avoiding a dual source of truth.
stateDiagram-v2
[*] --> Unassigned: created · agent unknown
[*] --> Incoming: created · agent known
Unassigned --> Incoming: Owner/Admin assigns
Incoming --> Incoming: reassigned
Incoming --> Closed_claims_created: add claim(s) + close
Incoming --> No_matching_passengers: no match + reason
No_matching_passengers --> Closed_claims_created: add claim (recovery)
No_matching_passengers --> Incoming: Return to active
Closed_claims_created --> [*]
stateDiagram-v2
[*] --> Filling_started: agent starts claim
Filling_started --> Claim_form_ready: enough data · form sent
Claim_form_ready --> Passenger_submitted: passenger signs + submits
Filling_started --> Passenger_declined: refused / already claimed
Claim_form_ready --> Passenger_declined: refused / already claimed
Passenger_declined --> Filling_started: Return to active
Passenger_submitted --> Reward_paid: in a paid payout batch
Reward_paid --> [*]
stateDiagram-v2
[*] --> Draft: system generates from accruals
Draft --> Reviewed: Account Manager checks
Reviewed --> Exported: payout file exported
Exported --> Paid: accounting pays + Mark as paid
Paid --> [*]: accruals & Claims locked
sequenceDiagram
autonumber
participant AG as Agency feed
participant SB as SkyCop Business
participant OAG as OAG + Scoring
participant AGT as Agent
participant PAX as Passenger
participant SC as skycop.com form
participant ACC as Accounting
AG->>SB: daily XLSX (flight data, no PII)
SB->>OAG: monitor each flight at/after departure
OAG-->>SB: disrupted + claimable
SB->>AGT: Flight lead (email + Kanban card)
Note over AGT: searches AGENCY system
for passengers on this flight
AGT->>SB: create Claim(s), enter passenger PII
AGT->>PAX: phone / WhatsApp — SELL the idea
AGT->>SB: generate link + Send email
SB->>PAX: templated email + secure form link
PAX->>SC: edit prefilled fields, upload docs, sign, submit
SC-->>SB: submission event
SB->>SB: Claim → Passenger submitted; accrual per passenger
Note over SB: existing SkyCop claim lifecycle (R2) takes over
SB->>ACC: monthly payout export
ACC-->>SB: Mark as paid → Claims → Reward paid
| Variant | Where it forks | Outcome |
|---|---|---|
| Unassigned | feed has no agent id | Owner/Admin must manually assign before any work starts |
| No matching passengers | agent can't find anyone on the flight in agency system | lead closed unworked (reason: not found / pax not on flight / other) |
| Passenger declined | passenger refuses or already claimed elsewhere | claim closed, no reward (+ reason + note) |
| Mis-click recovery | agent wrongly set decline / no-match | "Return to active" or add-claim auto-reopens |
| Reassignment | Owner/Admin moves lead to another agent | new owner gets access + email; old owner keeps only a saved deep link; others blocked (non-enumerable IDs) |
Each point restates what the PRD says (context), then my take and a recommendation — so you don't have to re-read the doc to follow it.
The architecture is sound and the GDPR instinct is excellent — the PII-free feed is the kind of decision that prevents a year of pain. The two things that decide whether this works are not in the software: (1) can agents actually reverse-match flights to passengers fast enough to bother (R1), and (2) is the scoring model tight enough that reward-on-submission doesn't bleed money (R3).
I'd run the BPC pilot instrumented to answer exactly those two questions before committing to the multi-agency connector framework. The biggest engineering risk is R4 — touching the live form plus the legacy submission event — so keep the pre-filled flow isolated from the paid-search funnel.