Prepared by Chester Bella · BA case study · 2026-09-16 · Download PDF
BA case study · epic pack

Customer identification and CRM integration

An epic the squad can build and the Bank would recognise. Read the first box; open the rest when you want to push on it.

In two minutes

Resolve the identity once, at the start, under rules an auditor can read. Show, write and keep nothing the Bank does not need. Never gate a branch on someone else's uptime.

The phase rule. A story is phase one only if, without it, an advisor cannot identify the person in front of them, or go-live creates wrong, duplicated or non-compliant customer data (branch confidentiality, flag guard, audit record, retention). Anything that only makes the path faster or richer is phase two.

The judgement calls

CallDecision
Branch scopingCustomers of other branches stay invisible to the advisor at go-live.
CRM unavailableThe advisor keeps typing into a draft marked "identification pending".
Prospect purge timingEvery prospect gets a delete-after date stamped at go-live (configurable; assumed 6 months after last activity, 30 days for an abandoned draft).
Seven more, from the hostile review of the acceptance criteria and two follow-up questions
Flag chip on result rowsShown only after the advisor selects a row; the deceased or blocked stop still fires before the case starts.
A blocked release and the next live re-readA release is recorded against the case with the flag value seen at release; a later re-read re-blocks only if that value changed (assumption, Bank compliance to confirm).
Owners of the out-of-scope alert and the merge queueThe Bank names both roles before the squad starts; they are configuration and never sit inside the requesting branch.
Subject access requestsAn export per person at go-live (prospect, snapshot, lookup-log entries) through the audit reader role.
Search keysExact keys find the person (customer number, IBAN, ID document number); fuzzy fields confirm (name, date of birth, place of birth); address is never a search input.
Place of birthAn optional third fuzzy input and a row column at go-live, if the CRM holds it; never required.

12 stories

What must be true first 6 of 28 assumptions

AssumptionWho confirms
Roles, fields, case trail, framework, several applicantsOper platform team
Merge queue and in-review state configurableOper platform team
Connector parameters: cache 10 minutes, client timeout 10 seconds, create wait 60 seconds, backoff 1 second doubling to 30, jitter, 5 attempts, idempotency record 30 days, local note 90 daysOper platform team
Configuration applies without a releaseOper platform team
Scope comes from the credentialCRM team, CRM question 1
Flags on the selected record, snapshot fields on detailCRM team, CRM questions 5 and 4

What we ask first 6 of 19 questions

QuestionWho
Is branch scope taken from the credential or from a request parameter?CRM team
Rate limits in numbers, per what (client, branch, user), and what a 429 returns.CRM team
Fuzzy algorithm, match score, stable ordering, maximum result count, paging, "too many results" behaviour.CRM team
Which fields differ between a search hit and the detail record?CRM team
Legal basis the DPO records, and whether the privacy notice covers the lookup.Bank
Retention period for a non-converted prospect and for an abandoned draft.Bank

What can go wrong 5 of 13 failure modes

FailureWhat the advisor seesWhat the system does
Search times out at 10 sLookup unavailable, keep typingIdentification pending, submit blocked, nothing written
CRM down an hourSame bannerDegraded capture, lookup re-runs later, gate holds
429 rate limitedShort wait, then resultsRetry-After honoured, else base 1 s doubling to 30 s, jitter, 5 attempts
Slow, p95 above targetLonger spinnerCache served where valid, latency alert
Out-of-scope record returnedNothing rendersDropped; the alert to the named role names no customer or number

How I would run it

First workshop with the Bank, one hour

The 19 open questions, in this order: the 4 that change acceptance criteria (scope from credential or parameter, flags on the hit or on detail, IBAN and place of birth as inputs, idempotent create), then the roles the Bank must name (release role, alert and merge-queue owners), then retention and legal basis. Every answer lands as configuration or as a changed criterion, the same day.

Definition of ready for the squad

A written CRM contract, a per-branch rate budget in numbers, a sandbox with realistic data, a schema version to pin. Until then the squad builds against a mock. This gates one sprint, not the go-live.

When the Bank pushes everything into phase one

Apply the rule story by story, in the room: does going live without it create wrong, duplicated or non-compliant customer data? Address and phone search, the exists-elsewhere signal and the update path fail that test; the flag guard, the audit log and the retention stamp pass it. The rule, not the loudest voice, decides.

When a stakeholder disagrees with branch scoping

The wall is on the advisor's screen, not on the data. The unscoped match at the push still stops duplicates, in the back office, where compliance already trusts people. If the DPO signs off a neutral existence signal, it moves into phase two with a measured number behind it.

1. The judgement calls in full3 calls with the push-back and the answer, 7 more from the reviews

Three questions had two defensible answers. Each was decided on a branch-day scenario: who is in the chair, what happens under each option, what would flip the call.

Call Decision Why The push-back, and the answer
Branch scoping Customers of other branches stay invisible to the advisor at go-live. Duplicates are still prevented: the create at the push milestone runs an unscoped match in the back office and routes hits to a queue the advisor never sees. A neutral "exists elsewhere" signal is phase two, behind a written DPO answer. "Compliance is strict about this" is the one note with no wiggle room. An existence signal is a disclosure. This removes the duplicate risk without asking compliance for anything at go-live, and it gives phase two a measured number instead of an argument. "The wall recreates the duplicates you were hired to fix." The wall is on the advisor's screen, not on the data. The unscoped check runs where compliance already trusts people.
CRM unavailable The advisor keeps typing into a draft marked "identification pending". Nothing can be submitted or pushed until the lookup succeeds; nothing is written to the CRM. Rate limits are retries with backoff, never an outage. An outage that stops every branch is the incident that ends the pilot. This costs one status and one gate, not a reconciliation engine: the pending draft re-runs the same lookup later. Nothing irreversible can happen while pending. "Degraded mode creates duplicates." It cannot reach the CRM, so it cannot.
Prospect purge timing Every prospect gets a delete-after date stamped at go-live (configurable; assumed 6 months after last activity, 30 days for an abandoned draft). The nightly purge job is phase two. From go-live a monthly report lists overdue prospects and the back office deletes them by hand. The stamp cannot be reconstructed later; the job has runway. Legal has not given a number, so the period is configuration. The report closes the only real exposure: a due record with no deletion path. "Retention automation is classic phase two." Agreed, as long as the date is stamped from day one and a deletion path exists. If legal sets under 3 months, the job moves to phase one.

Seven more calls came out of the acceptance criteria: five from the hostile review, two from follow-up questions on the search inputs.

Call Decision Why
Flag chip on result rows Shown only after the advisor selects a row; the deceased or blocked stop still fires before the case starts. The chip's job is to stop a flagged person entering a case, and selection is the first moment that can happen. On every row it disclosed the status of 9 strangers.
A blocked release and the next live re-read A release is recorded against the case with the flag value seen at release; a later re-read re-blocks only if that value changed (assumption, Bank compliance to confirm). Without this the four-eyes release is theatre. Any change in the CRM flag re-blocks, so the guard never weakens.
Owners of the out-of-scope alert and the merge queue The Bank names both roles before the squad starts; they are configuration and never sit inside the requesting branch. The only two places where a human reads cross-branch data; the holder is a compliance control owner and Oper must not pick it.
Subject access requests An export per person at go-live (prospect, snapshot, lookup-log entries) through the audit reader role. The phase rule puts non-compliant data in phase one; the pack had promised the lookup log in access responses without building the export.
Prospects due before the purge job exists Covered by the monthly overdue report above. A 30-day abandoned-draft clock makes a due record in the first weeks likely.
Search keys Two classes. Exact keys find the person and at most 1 record answers: the customer number at go-live, the IBAN at go-live if the CRM search endpoint accepts it, otherwise the first item of phase two, and the ID document number in phase two. Fuzzy fields confirm the pick and may return many, capped at 10: name plus date of birth. Address is never a search input; it is shown after selection to confirm. An exact key that returns 2 or more records means the CRM holds a duplicate: nothing renders, an alert goes out, and both records go to the merge review queue. Exact and in the room finds the person, a card or an ID. Fuzzy and shared confirms the pick. Address is shared by households and changes at exactly the moment a mortgage is applied for, so it separates nobody and adds noise. IBAN and ID document number are unique, stable and already in the advisor's hands.
Place of birth At go-live, if the CRM holds it, place of birth is an optional third fuzzy input next to the required name and date of birth, and a column on the result rows. It is never required. Over 10 hits the refine step asks for place of birth first, then a customer number, IBAN or ID document number. Place of birth is on every ID card, never changes, and separates the rare namesakes who share a date of birth. If it were required, a typo would hide the real customer and create the duplicate the epic exists to stop. Name and date of birth find the list; place of birth shortens it; the card or the ID ends it.
2. Current state, target state, failure modesthe live map, plus one render of each

Interactive map: live flow map (three tabs: current, target, failure; pick a flow, step through it hop by hop, click a node for its assumption).

Current state

Target state

Failure modes

3. User stories with acceptance criteria12 stories, 55 criteria, one story opens at a time

Customer identification and CRM integration

Advisors cannot see whether the person is already a customer, so duplicates grow.

Borrower portal (D13). The portal build is out of scope for this epic. The data boundary is in scope: portal sign-ups land in the same prospect store, same retention clock, same resolution check at the milestone gate.

Through-line. Resolve the identity once, at the start, under rules an auditor can read. Show, write and keep nothing the Bank does not need. Never gate a branch on someone else's uptime.

The phase rule (D12, verbatim). A story is phase one only if, without it, an advisor cannot identify the person in front of them, or go-live creates wrong, duplicated or non-compliant customer data (branch confidentiality, flag guard, audit record, retention). Anything that only makes the path faster or richer is phase two.

Case states. Identification pending: set when the lookup cannot complete, cleared when it completes. Unresolved: a party without a resolved identity. Abandoned: a prospect with no edit for 30 days. Break-glass: the named bypass role starts a case while a party is unresolved; each use logs user, time, reason and is reviewed within 1 working day. Assumption: abandoned is 30 days (Bank, Bank question 2); break-glass review within 1 working day (Bank compliance).

Stories

S1 Look up the customer first Phase 1

As an advisor, I want an unskippable lookup, so that re-typing stops. Decisions: D1, D2, D10, D12. Source: "look the customer up". Phase: 1 Product: OOTB: roles, steps, integration framework | Config: gate flag, fields: customer number, IBAN, name, date of birth, place of birth | Engineering: CRM connector, lookup component, break-glass capture Assumption: the case model holds several applicants with roles, each resolved separately (Oper platform team); the CRM search takes IBAN as an exact key (CRM team, CRM question 11); the CRM holds place of birth (CRM team, CRM question 11); the legal basis is pre-contractual steps at the person's request, not consent, no consent screen (Bank DPO, Bank question 1). - Given any unresolved party, when the case moves to the next configured step, then progression refuses; typing continues. - Given customer number or IBAN (exact), or name, date of birth, optionally place of birth (fuzzy), when submitted, then 1 search runs. - Given break-glass, when an advisor tries, then refused; only the named bypass role passes.

S2 Pick the right person Phase 1

As an advisor, I want thin rows, so that I pick correctly. Decisions: D2, D3, D11, D12. Source: "the right person". Phase: 1 Product: OOTB: none | Config: columns, cap 10, snapshot | Engineering: search, match, link model, snapshot diff, task Assumption: snapshot is name, birth date, address, contact, number (CRM team, CRM question 4); the session cache lives 10 minutes (Oper platform team). - Given an overflow flag, when rendered, then no rows, no count; refine asks place of birth first, then an exact key. - Given 10 or fewer, when rendered, then name, birth date, place of birth, city, masked number; no flag chip. - Given 1 exact key hit, customer number or IBAN, when rendered, then that row preselects; the advisor confirms. - Given an exact key, when 2 or more records return, then nothing renders; alert; merge review queue, unseen by the advisor. - Given a row, when selected, then detail loads for that row only; the flag chip shows before the case starts. - Given a confirmed row, when saved, then number and dated snapshot store; changed fields raise milestone tasks. - Given same advisor and query within 10 minutes, when re-run, then rows reuse; flags are never cached.

S3 Keep branches invisible Phase 1

As a compliance officer, I want branch-only results, so that nothing leaks. Decisions: D4 (C1), D12. Source: "other branches' customers". Phase: 1 Product: OOTB: none | Config: branch attribute, alert role | Engineering: filter, alert, counter Assumption: scope comes from the credential (CRM team, CRM question 1); the Bank names the alert role, outside the requesting branch (Bank, Bank question 8). - Given credential scoping, when searching, then no other branch's row reaches Oper; Oper filters again. - Given an out-of-scope record, when filtered, then dropped; the named role is alerted, without customer name or number. - Given no hit, whatever the cause, when rendered, then 1 not-found message; create offered; the milestone re-match still runs.

S4 Stop flagged customers Phase 1

As a compliance officer, I want flagged people stopped, so that no blocked or deceased person enters a loan. Decisions: D5, D12. Source: "has to be a guard". Phase: 1 Product: OOTB: roles | Config: flag map, milestones | Engineering: guard, re-read, dispute request Assumption: flags live on the selected record (CRM team, CRM question 5); a release holds until the flag value changes (Bank compliance); disputed flags fixed within 1 working day (Bank compliance). - Given deceased, when read, then hard stop before the case starts; no override. - Given blocked, when released, then a second role outside the advisor's line types a reason; audit names the approver. - Given a release, when recorded, then the case stores the flag value seen; a change re-blocks. - Given no release role, when blocked is met, then blocked is a hard stop. - Given an unmapped flag value, when received, then Oper fails closed; mapping needs compliance approval. - Given any configured milestone, when reached, then every party's flags read live; an unreleased stop blocks progression. - Given a disputed flag, when raised, then an urgent correction reaches the CRM owner.

S5 Create and push Phase 1

As an advisor, I want in-flow creation, so that a new customer never leaves the flow. Decisions: D6, D7 (C3), D11, D4, D12. Source: "then and there". Phase: 1 Product: OOTB: none | Config: milestone, retention, queue role | Engineering: prospect store, idempotent create, unscoped job, report Assumption: retention 6 months after activity, 30 days abandoned (Bank, Bank question 2); the merge queue role sits outside the requesting branch (Bank, Bank question 8). - Given no match, when creating, then a prospect stores in Oper only, delete-after stamped: 6 months after activity, 30 days abandoned. - Given the submit milestone, when pushing, then a back-office job re-matches unscoped under its own credential. - Given a hit, when pushing, then no customer; the Bank-named role works the queue, unseen by the advisor, case in review. - Given no hit, when creating, then the prospect id keys idempotency; without support, search by key first. - Given the pinned schema, when answered, then additive changes pass; removals alert, identity or flag removals fail. - Given the monthly report, when run, then prospects past their delete-after date list; the back office deletes them.

S6 Log every lookup Phase 1

As an auditor, I want searches and picks recorded, so that every lookup can be reconstructed. Decisions: D8, D12, D14. Source: "who searched for what". Phase: 1 Product: OOTB: audit trail | Config: retention, reader role | Engineering: lookup log, person export Assumption: log kept 7 years, in subject access responses (Bank DPO, Bank question 3); erasure leaves audit entries under a documented basis (Bank DPO); an unechoed id joins by timestamp and credential (CRM team, CRM question 10). - Given a search, when logged, then 1 entry: time, advisor, branch, query, rows shown, total matches, ids ordered, correlation id. - Given a pick, creation, release, refusal or break-glass, when logged, then 1 entry: event, actor, reason where captured. - Given the unscoped re-match, when run, then 1 entry: job, case, hit count. - Given any entry, when written, then named fields only, never payloads; append-only; reads log reader, time, scope. - Given no audit role, when opening, then refused; readers see their own branches only. - Given a person request, when the audit reader exports, then prospect, snapshot and lookup-log entries return.

S7 Survive CRM outages Phase 1

As an advisor, I want outage tolerance, so that branches keep running. Decisions: D9 (C2), D1, D12. Source: "something about rate limits". Phase: 1 Product: OOTB: none | Config: rate budget | Engineering: pending state, block, retry Assumption: rate limits, units, 429 behaviour (CRM team, CRM question 2); client timeout 10 seconds (Oper platform team). - Given a timeout after 10 seconds, when searching, then the draft marks identification pending; typing continues. - Given identification pending, when submitting or pushing, then progression refuses; nothing writes. - Given a 429, when retrying, then retry-after honoured, else backoff base 1 second doubling to 30, 5 attempts. - Given the CRM returns, when the advisor re-runs the lookup, then guards apply; pending clears; no reconciliation.

S8 Search by ID document number Phase 2

As an advisor, I want more identifiers, so that matches rise. Decisions: D2, D12. Source: "address or phone". Phase: 2 Product: OOTB: none | Config: fields: ID document number, phone; IBAN if refused at go-live | Engineering: none or a CRM change Assumption: the endpoint indexes ID document number as an exact key (CRM team, CRM question 11); a renewal changes that number (CRM team, CRM question 11); the search accepts phone (CRM team, CRM question 8); IBAN joins this story if refused at go-live (CRM team, CRM question 11); configuration applies without a release (Oper platform team). - Given an ID document number, when searched, then it runs as an exact key; S2 preselect and duplicate rules apply. - Given a renewed document, when the number changed, then the key misses; fuzzy fields resolve. - Given every other field failed, when phone filters the fuzzy result, then cap, guard and log hold. - Given a selected record, when detail loads, then address shows to confirm; address is never a search input. - Given the fields disabled, when rendering, then hidden; enabling needs the DPO's written sign-off.

S9 Signal existence elsewhere Phase 2

As an advisor, I want a details-free signal, so that referrals replace duplicates. Decisions: D4 (C1), D12. Source: "duplicate customers". Phase: 2 Product: OOTB: none | Config: signal switch, inputs | Engineering: existence check, fixed referral note on the no-match screen Assumption: the DPO permits a signal on exact identifiers and accepts surname-plus-birth-date collisions (Bank, Bank question 6). - Given the signal on, when exact number or surname plus birth date matches, then referral shows. - Given a fuzzy or partial search, when matched elsewhere, then no signal; the check reuses the back-office unscoped path. - Given a signal, when shown, then no person or branch named; the log records the key type only.

S10 Purge due prospects Phase 2

As a DPO, I want due prospects deleted, so that nothing lingers. Decisions: D7 (C3), D12. Source: "keeping prospect data forever". Phase: 2 Product: OOTB: none | Config: none | Engineering: nightly purge job, erasure path Assumption: the monthly report covers due prospects until this job ships (Bank, Bank question 2); a deferral past 12 months is reported to the DPO (Bank DPO). - Given a due prospect, when the nightly job runs, then deleted within 24 hours of the date. - Given a live case, when the job runs, then kept; deferral past 12 months reports to the DPO. - Given a verified erasure request, when received, then prospect and snapshot delete; audit entries stay under the documented basis.

S11 Route corrections back Phase 2

As a CRM owner, I want reviewed corrections, so that master data stays clean. Decisions: D11, D12. Source: "a customer's full detail". Phase: 2 Product: OOTB: none | Config: proposable fields, ownership flag | Engineering: change request, review screen Assumption: an update endpoint exists (CRM team, CRM question 9); a no means CRM engineering, not configuration; the local note expires after 90 days (Oper platform team). - Given a differing field at a milestone, when marked, then a change request reaches the CRM owner queue. - Given the change request, when approved, then Oper re-reads the detail record; actor and values log. - Given rejection, when continuing, then the CRM value stays master; the local note expires after 90 days. - Given the ownership flag set, when phase two ships, then an update path opens; the CRM stays writer of record.

S12 Resolve portal sign-ups Phase 2

As a CRM owner, I want portal sign-ups resolved, so that duplicates never refill. Decisions: D13, D6, D12. Source: "submit a mortgage application". Phase: 2 Product: OOTB: none | Config: resolution milestone | Engineering: portal intake contract, store reuse, match Assumption: a portal sign-up already creates a person record (Bank); the portal shows its own notice (Bank DPO). - Given a portal sign-up, when posted to the prospect intake, then same store, same stamp. - Given a portal case, when the application is submitted, then an unscoped re-match runs; hits go to merge review. - Given an advisor assigned, when the case opens, then their branch scopes it from then on. - Given a proposed match, when taken up, then nothing auto-applies; the assigned advisor confirms.

Phase table

Story Phase Reason
S1 1 Nobody is identified.
S2 1 Wrong identity on loans.
S3 1 Branch confidentiality breached.
S4 1 Flagged person loans.
S5 1 Duplicates, undated prospects.
S6 1 No audit record, no access answer.
S7 1 Every branch stops.
S8 2 Only faster; the CRM must index the keys.
S9 2 Only richer; DPO first.
S10 2 S5 stamp and report hold retention.
S11 2 No wrong data created.
S12 2 Out of scope; S5 ships rules.
4. Integration notesdata in and out, the 3 CRM calls, 13 failure modes, 11 questions, definition of ready

Integration notes: Oper and the Bank's CRM

1. Context

The Bank's CRM holds every customer in every branch; its API is unverified, see section 6.

The connector is 1 adapter in Oper's integration framework; bank rules stay in configuration. Assumption: framework, roles, case audit trail, configurable fields and steps exist (Oper platform team).

The CRM stays master of identity: number, flags, owning branch, details; Oper never updates an existing customer. Oper owns prospects (delete-after stamped), dated snapshots, and the lookup audit log.

2. Data flows

Direction Data When Purpose Personal data?
Into Oper Thin rows: name, date of birth, place of birth, city, masked number Go-live Pick the person Yes
Into Oper Customer detail by number, agreed field set Go-live Fill case, write snapshot Yes
Into Oper Status flags and values, on detail only Go-live Guard at selection and milestones Yes
Into Oper Branch marker per record Go-live Second filter, mismatch alert No
Into Oper Error codes, rate limit headers, overflow flag Go-live Backoff, forced refine No
Into Oper Unscoped match at milestone, back office Go-live Stop cross-branch duplicate Yes
Into Oper Customer number from create Go-live Link case to master record Yes
Into Oper Products, address history, segment Phase two Separate common names Yes
Into Oper Neutral existence signal on exact match, unscoped, at search time Phase two Referral without disclosure; needs a written DPO yes Yes
Out of Oper Exact keys: customer number, IBAN (CRM question 11); fuzzy: name, date of birth, place of birth (optional, CRM question 11); advisor id, branch, correlation id Go-live Find the person Yes
Out of Oper Customer number on detail, each live flag read Go-live Read selected record Yes
Out of Oper Create payload: identity fields, case reference, prospect id as key Go-live The 1 write Yes
Out of Oper Change request raised as a task to the CRM owner, no API write Go-live Correct master data Yes
Out of Oper Review screen, ownership flag, update path Phase two Write back agreed fields Yes
Out of Oper ID document number (exact), phone (filter) Phase two Better hit rate Yes

D11 at go-live is read plus 1 create.

3. The 3 calls

3.1 Search

  1. The gate blocks the next configured step, not typing. Inputs: customer number or IBAN as exact keys, or name plus date of birth, with place of birth optional; 1 weak field fires no call.
  2. Oper sends advisor id, branch, correlation id; the CRM applies scope. Assumption: scope from the credential (CRM team, CRM question 1).
  3. Session cache keyed by advisor plus query, in memory, flags excluded, cleared on scope change or sign-out. Assumption: 10 minutes (Oper platform team).
  4. Thin fields only, cap 10, no flag on a row; an overflow flag, not a count, forces refine, asking for place of birth first, then an exact key: customer number, IBAN or ID document number; no paging. Assumption: the hit carries city and masked number (CRM team, CRM question 4).
  5. Oper re-filters by branch; out-of-scope rows dropped. The alert reaches a role outside the requesting branch, never the advisor, and names no customer or number. The lookup log, not the alert, keeps the dropped id and both branches (D8). Assumption: the Bank names that role in configuration (Bank, Bank question 8).
  6. No auto-select; an exact key, customer number or IBAN, preselects 1 row.
  7. An exact key returning 2 or more records is a CRM duplicate: nothing renders, an alert routes it to the merge review queue, unseen by the advisor.
  8. Audit: time, advisor, branch, query, rows shown, total matches, ids ordered, correlation id; detail adds flags and schema version, create adds key and attempts.

3.2 Detail

  1. Advisor selects 1 row; others fetch nothing. The call sends the number and search correlation id.
  2. Flags reach Oper on detail, not on a row; they read live here and at each milestone, never cached. A detail read that finds nothing: no link, identification pending. Milestones at go-live: application submitted, offer produced. Assumption: 2 milestones, configurable (Bank).
  3. Pinned schema: the pin is a version string in connector configuration, owned by the squad, changed by release; in-flight cases keep theirs. A removal comes from the CRM's published version, never from a missing key.
  4. Unknown flag value fails closed; the map is corrected within 1 working day. Assumption: 1 working day (Bank compliance).
  5. Deceased: hard stop, no override. A disputed flag raises an urgent correction to the CRM owner.
  6. Blocked: a second role outside the advisor's reporting line releases, typed reason, audit names the approver. The release records the flag value seen; a later live re-read re-blocks only if it changed. Assumption: that rule holds (Bank compliance); that role exists at go-live and covers Saturday (Bank); otherwise blocked is a hard stop too.
  7. Pass: number stored as identity truth; dated snapshot written, re-read each milestone, on case retention, not the prospect clock. Assumption: case retention applies (Bank DPO).
  8. A changed field raises a task, never an overwrite; that task is the change request S11 reviews.

3.3 Create at the milestone

  1. No match: the advisor creates a prospect in Oper, inside the flow, stamped with a delete-after date; nothing reaches the CRM until the configured milestone, default "application submitted".
  2. Search re-runs first, unscoped, by a back-office job under its own credential, unseen by the advisor, with its own access control and audit.
  3. Hit: merge queue, worked by a role outside the requesting branch, write held, neutral in-review state, no reason. Entries kept 12 months after the decision. Assumption: the Bank names that role in configuration (Bank, Bank question 8); 12 months (Bank DPO); queue configurable (Oper platform team).
  4. No hit: create once, prospect id as idempotency key. Assumption: the CRM accepts a key (CRM team, CRM question 6).
  5. The idempotency record (id, attempts, status) sits with the prospect and expires 30 days after the create resolves. Assumption: 30 days (Oper platform team).
  6. Timeout: search by key, adopt if landed; else wait 60 seconds, search again, then queue. Never a blind second create. Assumption: 60 seconds (Oper platform team).
  7. Success: number linked, snapshot written, prospect state cleared.

4. Failure modes

Failure What the advisor sees What the system does What is logged
Search times out at 10 s Lookup unavailable, keep typing Identification pending, submit blocked, nothing written Correlation id
CRM down an hour Same banner Degraded capture, lookup re-runs later, gate holds Blocked submits
429 rate limited Short wait, then results Retry-After honoured, else base 1 s doubling to 30 s, jitter, 5 attempts Retries, headers, wait
Slow, p95 above target Longer spinner Cache served where valid, latency alert p95 per branch
Out-of-scope record returned Nothing renders Dropped; the alert to the named role names no customer or number Dropped id, both branches
Exact key returns 2 records Nothing renders Alert, merge review queue Both ids, key type, no key value
Detail not found for a shown row Row is stale, search again No link, identification pending Number, correlation id
Unknown flag value Contact back office Fails closed, mapped within 1 working day Value, number, version
Flag field missing Contact back office Call fails, identity not confirmable Field, endpoint, version
Create times out Finishing, do not retype Search by key, wait 60 s, search again, then queue Key, attempts
Duplicate returned on create In-review state, no reason Write held, merge review opened Both numbers, queue id
Schema drift Blank optional field, or hard stop on identity and flags Additive passes, published removal alerts Pinned version
Auth failure Lookup unavailable Calls stop, operations alerted, no unscoped fallback Credential id, error code

5. Non-functional

Rate budget per branch, unknown until CRM question 2. Size per party, not per case: each applicant costs 1 search, 1 detail and 1 live flag read per milestone, plus retries, in sequence. Assumption: backoff base 1 s doubling to 30 s, jitter, 5 attempts (Oper platform team).

Latency. Assumption: search under 2 seconds at p95 (CRM team). Client timeout above the agreed p99, not p95. Assumption: 10 seconds (Oper platform team).

Lookup audit log: append-only, identifiers not payloads, restricted role scoped to its own branches, reads logged in the same log and retention. The log, not a repeat query, is the evidentiary record; CRM ordering may be unstable. Assumption: 7 years, own clock (Bank DPO, Bank question 3); CRM access log kept at least as long (CRM team, CRM question 10).

Subject access: 1 export per person reads prospect, snapshot and lookup log through the audit reader role; append-only entries stay under a documented basis on erasure. Assumption: that basis is documented (Bank DPO).

Reason fields carry the business ground only, never health or family detail. Assumption: the wording is agreed (Bank compliance).

Prospect retention configurable. Assumption: 6 months after last activity, 30 days for an abandoned draft (Bank, Bank question 2). Stamp at go-live, purge job phase two, before the first stamped date falls due. Until the job ships a monthly report lists prospects past their delete-after date and the back office deletes them by hand.

Change requests: 1 queue in Oper. Assumption: under 20 a week, reviewed within 5 working days (Bank).

6. Open questions for the CRM team

# Question What changes with the answer
1 Scope from credential or request parameter? Parameter: our filter is the only guard. Credential: 1 per branch.
2 Rate limits in numbers, per what unit, and the 429 response? Sets ceiling, cache lifetime, backoff.
3 Fuzzy algorithm, stable ordering, overflow flag, paging, exact-versus-fuzzy marker per hit? Unstable ordering: audit cannot prove what was shown. No marker: S9 cannot gate on exact.
4 Which fields differ between a search hit and the detail record? Missing city or number: the row omits it; never a detail call per row (D3).
5 Are deceased and blocked on the hit or only detail, and who versions the flag values? Detail-only suits the guard, which reads at selection; values become the flag map, others fail closed.
6 Create idempotent with key support, and does the CRM deduplicate? No key: search before every retry, wider duplicate window.
7 Sandbox with realistic data, and a schema version to pin? Without it, fuzzy-behaviour criteria stay untested.
8 Does the search endpoint accept phone as an input, and how fuzzy is it? (Address is no longer a search input, E6.) Yes: phone switches on in phase two as a last-resort filter (D2); no: a CRM change first.
9 Is there an update endpoint, and which fields may a channel change? Yes: phase-two write-back once ownership is agreed; no: corrections stay change requests.
10 Does your access log store our correlation id, and for how long? No echo: join by timestamp plus credential. Shorter retention: identifications stop reconstructing.
11 Does the search endpoint accept IBAN, ID document number and place of birth as inputs, and are they indexed as exact keys? Which of them does the CRM store at all? Yes: IBAN is a go-live exact key, ID number a phase-two one, place of birth a go-live input and result column; no: customer number stays the only go-live exact key, IBAN becomes the first item of phase two (S8), ID number needs a CRM change, and name plus date of birth stay the only fuzzy inputs.

7. Definition of ready for the squad

The squad can start when 4 things exist.

  1. Written CRM contract: endpoints, authentication, scope mechanism, field lists, flag list with values, error codes, pagination, idempotency on create, and the unscoped back-office credential.
  2. Per-branch rate budget in numbers, including the ceiling the connector enforces.
  3. Sandbox with realistic data: common surnames, flagged records, records outside the caller's branch.
  4. Schema version to pin, with flag values versioned as well as fields.

Until all 4 arrive, the squad builds against a mock; this gates 1 sprint, not the go-live.

5. Prioritisation, assumptions, questionsthe rule applied to all 12 stories, 28 assumptions with owners, 19 questions

The rule

A story is phase one only if, without it, an advisor cannot identify the person in front of them, or go-live creates wrong, duplicated or non-compliant customer data (branch confidentiality, flag guard, audit record, retention). Anything that only makes the path faster or richer is phase two.

Go-live core vs phase two

Story Title Phase Reason Trigger
S1 Look up the customer first 1 Nobody is identified n/a
S2 Pick the right person 1 Wrong identity on loans n/a
S3 Keep branches invisible 1 Branch confidentiality breached n/a
S4 Stop flagged customers 1 Flagged person loans n/a
S5 Create and push 1 Duplicates, undated prospects n/a
S6 Log every lookup 1 No audit record, no access answer n/a
S7 Survive CRM outages 1 Every branch stops n/a
S8 Search by ID document number 2 Only faster; the CRM must index the keys CRM question 11 answered yes for at least 1 key (IBAN joins this story if refused at go-live), or advisors hit the refine wall on hit-rate data
S9 Signal existence elsewhere 2 Only richer; DPO first A written DPO yes
S10 Purge due prospects 2 S5 stamp and report hold retention First stamped date nears, or legal sets under 3 months
S11 Route corrections back 2 No wrong data created Field ownership agreed, CRM question 9 yes
S12 Resolve portal sign-ups 2 Out of scope; S5 ships rules Borrower portal enters a go-live

What the Bank will push on, and the answer

Branch wall. They say the wall recreates duplicates; it covers the advisor's screen, not the data, because the push re-matches unscoped.

CRM outage. They say degraded capture creates duplicates; a pending draft cannot reach the CRM, so it cannot write.

Purge timing. They want the job now; the stamp cannot be rebuilt later; a monthly report lists every prospect past its delete-after date and the back office deletes them by hand until the job ships.

Assumptions

# Assumption Who confirms If wrong
1 Roles, fields, case trail, framework, several applicants Oper platform team Configuration becomes engineering
2 Merge queue and in-review state configurable Oper platform team The queue needs building
3 Connector parameters: cache 10 minutes, client timeout 10 seconds, create wait 60 seconds, backoff 1 second doubling to 30, jitter, 5 attempts, idempotency record 30 days, local note 90 days Oper platform team Advisors wait longer, or a create repeats
4 Configuration applies without a release Oper platform team S8 fields need a deploy
5 Scope comes from the credential CRM team, CRM question 1 Only our filter guards
6 Flags on the selected record, snapshot fields on detail CRM team, CRM questions 5 and 4 Extra calls, thinner snapshot
7 Ordering, cap, rate limits as assumed CRM team, CRM questions 3 and 2 Audit weak, backoff guessed
8 Create takes our idempotency key CRM team, CRM question 6 Search before every retry
9 The access log keeps our correlation id CRM team, CRM question 10 Joins run on timestamp and credential
10 The CRM access log is kept at least 7 years, as long as ours CRM team, CRM question 10 The join has a shorter evidence window than the lookup log
11 Search under 2 seconds at p95 CRM team Advisors feel a block
12 Search takes phone as a last-resort filter, update endpoint exists CRM team, CRM questions 8 and 9 S8 and S11 blocked
13 IBAN searchable as an exact key CRM team, CRM question 11 Customer number stays the only go-live exact key; IBAN becomes the first item of phase two (S8)
14 Place of birth held and searchable, so it is a go-live optional input and result column CRM team, CRM question 11 Name plus date of birth stay the only fuzzy inputs, no place-of-birth column
15 ID document number stored and indexed as an exact key CRM team, CRM question 11 S8 needs a CRM change first
16 Retention 6 months after activity, 30 days abandoned; the monthly report covers due prospects until the purge job ships Bank, Bank question 2 Stamps wrong, a due prospect has no deletion path
17 An advisor serves 1 branch, unchanged mid-case Bank, Bank question 5 Scope moves mid-case
18 Release role staffed, Saturdays too Bank, Bank question 4 Blocked is a hard stop
19 DPO allows a signal, portal creates a record Bank, Bank question 6 S9 and S12 change
20 Alert and merge queue roles named, outside the branch Bank, Bank question 8 Oper picks a control owner
21 2 milestones at go-live, configurable; change requests under 20 a week, reviewed within 5 working days Bank A milestone re-read is missed; S11 needs staffing
22 Legal basis is pre-contractual steps, not consent Bank DPO, Bank question 1 Consent screen, deletion consequence
23 Lookup log kept 7 years, in subject access responses Bank DPO, Bank question 3 Log rules change
24 Snapshot on case retention not the prospect clock, merge queue entries 12 months, audit entries survive erasure under a documented basis, deferral past 12 months reported Bank DPO Purge clocks and the erasure path change
25 The portal shows its own privacy notice Bank DPO Oper carries the portal notice
26 A release holds until the flag value changes Bank compliance Every milestone re-approves
27 Disputed flags and unknown flag values corrected, break-glass use reviewed, each within 1 working day Bank compliance Cases sit blocked, bypasses unreviewed
28 Reason field wording agreed, business ground only Bank compliance Reasons carry health or family detail

Questions for the CRM team

  1. Is branch scope taken from the credential or from a request parameter?
  2. Rate limits in numbers, per what (client, branch, user), and what a 429 returns.
  3. Fuzzy algorithm, match score, stable ordering, maximum result count, paging, "too many results" behaviour.
  4. Which fields differ between a search hit and the detail record?
  5. Are deceased and blocked on the search hit or only on detail? Full flag list and values.
  6. Is create idempotent (key support), and does the CRM deduplicate on create?
  7. Sandbox with realistic data, and a schema version we can pin.
  8. Does the search endpoint accept phone as an input, and how fuzzy is it? (Address is no longer a search input, E6.)
  9. Is there an update endpoint for existing customers, and which fields would the CRM let a channel change?
  10. Does your access log store our correlation id, and for how long?
  11. Does the search endpoint accept IBAN, ID document number and place of birth as inputs, and are they indexed as exact keys? Which of them does the CRM store at all?

Questions for the Bank

  1. Legal basis the DPO records, and whether the privacy notice covers the lookup.
  2. Retention period for a non-converted prospect and for an abandoned draft.
  3. Retention and access rights for search logs; inclusion in subject access responses.
  4. Which role may release a blocked customer; is four-eyes accepted; who holds it on a Saturday.
  5. Can one advisor serve several branches, and can that change mid-case?
  6. Is a cross-branch "exists elsewhere" signal with no details permitted? (unlocks phase two)
  7. Is the borrower portal part of this go-live?
  8. Which role receives the out-of-scope alert and which role works the merge review queue? Neither may sit inside the requesting branch.
6. How this was producedthe method in 6 steps; the full log is the separate AI working log

The pack was produced AI-native, with one fixed method and three human checkpoints.

  1. The brief went in verbatim. Every workshop note was read for the need behind it and for what breaks if only the surface ask is built.
  2. Fourteen decisions were written as Option A / Option B. Three independent AI lenses answered them blind to each other: a delivery analyst, the Bank's compliance and CRM owner, a platform architect. Eleven answers were unanimous; the three splits were decided by a human on branch-day scenarios.
  3. Maps, stories, integration notes and priorities were built from the decided spec, in fixed formats and word budgets, in parallel.
  4. Every artefact passed a conformance review: a fresh read, blind to the author, checked it against the decisions, the format and the brief, and the findings were applied until the review passed. This loop caught a write-back path that contradicted a decision, six clauses lost in a cut for length, and a false retention runway.
  5. A hostile review in three roles, a squad developer, the DPO and the CRM team lead, attacked all 55 acceptance criteria: 115 findings, merged into 76 issues, 64 fixed, 7 defended, 5 escalated to the human and decided, and 2 further calls came from the author's own questions (search keys, place of birth).
  6. Where AI was not trusted: agreement across blind lenses counted as signal and disagreement went to a human; a review could not re-open a decision; maps were verified by rendering and reading the image, never by a build that returned no error; every gap is labelled as an assumption with an owner rather than filled by a model.

The full step-by-step log is in the appendix.

Appendix: the AI working log, one row per step, incl. the reusable tooling built for this case.