Hackathon challenge 4 · Advanced · Cloud & AI Platforms
Customer Intelligence Engine
Live Customer 360, behavioural segments and early churn warnings.
“You find out a customer left after they've already left. Build the AI that warns you 3 months early.”
Challenge card
Build
26 Oct – 6 Nov 2026
Video
5–10 minutes
Scenario
Mortgage Renewal Early Warning
Status
Proposal · not built
Proposed warning: about 90 days before a fixed-rate deal ends.
Illustrative
Scroll sideways to see the whole figure.
Here, deal end means the end of the fixed interest-rate period, not repayment of the whole mortgage. Churn means confirmed refinancing with another lender. The 90-day warning is a proposed target, not a measured result. The team must test it against actual refinancing dates.Why this form
A time line shows the gap between finding the loss and having time to act. Trade-off: it hides the system design. Each blueprint page shows the architecture.
What the challenge asks for
Four requirements from the challenge card. Fabric is central. The suggested components are not mandatory.
1
Real-time Customer 360
Join live customer activity with history in one view.
Eventstream · Eventhouse
2
ML segments
Group customers by behaviour with a machine-learning model.
Fabric Data Science · MLflow
3
Churn model, about 90 days ahead
Score the risk that a customer leaves, and show the drivers behind each score.
Fabric Data Science · MLflow
4
Retention alert on live events
Fire an alert when a live event changes the picture, and send it to a person.
Activator · Power BI
Deliverable: churn risk scores with drivers, and a retention alert that fires on live events.
How we win
50 of 100 points
Business value and solution quality together carry 50 of 100 points. We prioritise a working, clear retention story over extra features.
Optional suggestions · stretch
The challenge page's “Solution” text lists ideas. The organiser says they are suggestions, not requirements. The blueprint includes KQL journey queries, segment history, accuracy and lift, Direct Lake and Purview sensitivity labels. Identity resolution, a Fabric IQ ontology and a Copilot Studio retention brief are stretch features. Building a custom software application, autonomous discounts and multiple agents are out of scope.
Milestones
Scenario chosenThe team chose the mortgage scenario.
Idea submissionSend the blueprint form. The submission pack has the answers.
BuildData, model, alert and demo.
Solution submissionInclude a 5–10 minute video.
The slide gives PST as the deadline timezone. Check the organiser's intended timezone.
The chosen blueprint
The illustrative mortgage provider is HomeBridge, a fictional company. The blueprint page gives the full design. The submission pack gives the form answers and the files to upload.
These are design judgements, not researched market rankings. The insurance scenario (HavenCover) and three earlier scenarios (software, broadband and retail) are archived and hidden.
Shared core: three clocks
Proposed target
The blueprint uses three timing targets. A live event and an ML score refresh are separate operations. The demo shows and measures both.
60 s
From a live event to its appearance in the Customer 360 view.
15 min
Between scoring runs that refresh features, assign segments and calculate refinancing risk scores. These runs do not retrain the models.
5 min
From a successful scoring run to the retention alert.
Measure ingestion, view refresh, scoring and alert delivery separately. These are targets to test, not platform guarantees.
A scheduled Lakehouse export alone is not a real-time view. Live events go through Eventstream into Eventhouse.
A notebook started by hand is a test drill. The final design runs scoring on a schedule.
A failed scoring run leaves the last score marked stale. The live view still updates.
Do not claim more than the evidence shows
“90 days early”
Calculate the score 90 days before renewal. Freeze the information available at that checkpoint. Evaluate the later renewal outcome. Predicting churn "within 90 days" does not establish 90 days of warning. If the warning comes later, report the failed target.
“We know why”
Feature attributions explain how model inputs affect the score. Checked events support investigation. Neither proves the customer's true motivation. Neither proves that a retention action will work.
“We saved revenue”
A demo can show recurring revenue at risk and recorded actions. Proving improved retention requires evidence from real retention actions and a comparison group. Synthetic results prove only that the process works.
Show the proof
What the demo and video must show.
Test on a later time period that training excludes. Do not use information from after each feature snapshot.
Compare the model with a simple rules baseline.
Measure precision: the share of flagged customers that churn. Measure recall: the share of churned customers that the model flags.
Evaluate precision and recall at the number of customers the team can contact.
Measure lead time for each confirmed leaver: outcome_at minus first_eligible_warning_at. Report the distribution.
Show one live event that creates exactly one retention case. Keep a record that supports an audit.
Show a healthy or seasonal customer, not only the scripted failure.
Demonstrate ML segments and alert-routing rules separately. Do not label rules as ML.
Access, Fabric capacity, alert integration, team availability and the dataset's source remain unconfirmed. Check these before promising the final stack.
What we submit
Two submissions: the blueprint form on 18 October and the solution on 6 November.
Hackathon proposal. Fictional business and proposed targets. No implementation results are claimed.
Terms on this page: a product-transfer request is the customer's mortgage application for a new deal with HomeBridge. The renewal portal is HomeBridge's software for that request. Payment support means help with mortgage payments. Technical support investigates verified portal faults.
Company, customer and counterexample (illustrative)
The company and customer
HomeBridge is a fictional mortgage lender. It services repayment mortgages and offers product transfers when fixed-rate deals end.
The customer unit is one mortgage account, not an individual borrower. Joint borrowers remain linked parties, not duplicate customers. A servicing adviser owns each renewal review.
The problem and counterexample
Score external refinancing risk at the checkpoint, 90 days before the fixed-rate deal ends. Payment-support needs take priority over commercial retention reviews.
Alex reports concern about future payments while the renewal portal repeatedly fails during a product-transfer request. The adviser must inspect both problems.
Sam completes a product transfer without payment problems. A quiet renewal-portal history alone does not justify an alert.
Build specification at a glance
The rules that must hold, the data shape, and the failure cases the demo must pass. Full detail is in the sections below.
Invariants
INV-1An active payment-support request routes to trained servicing staff first, whatever the churn score.
INV-2Features use only data known at the checkpoint. Both occurred_at and ingested_at must be at or before cutoff_at.
INV-3At most one open internal review case exists per mortgage_id + cycle_id + action_family.
INV-4An unknown or incomplete refinancing outcome gets no model label. It never counts as retained.
INV-5risk_updated fires only after a scoring run succeeds. A failed run leaves the last score marked stale.
INV-6The prototype sends no customer messages. It makes no rate or credit decisions.
Data contract
Mortgage account
One loan account and fixed-rate deal cycle.
Payment
One posted ledger change.
Transfer request
One product-transfer request state change.
Servicing history
Source case state changes and dated contacts linked to each case. These are separate from a new review case.
Feature snapshot
One mortgage, deal cycle and cutoff time. The observed refinancing outcome stays separate.
Segment assignment
One mortgage account, deal cycle and scoring run.
Key: mortgage_id + cycle_id. The cycle identifies a fixed-rate deal, not a scoring run. Every event carries event time and ingestion time. The risk_updated event carries snapshot, model version, refinancing risk score, segment, evidence IDs and score time.
Failure cases the demo must pass
ID
Case
Expected result
T01
The same eligible event is replayed.
One review case for the same case key.
T02
An unknown account or a conflicting borrower mapping arrives.
The record goes to quarantine.
T03
The payment feed is stale or missing.
The view flags the feed as stale. A missing feed is not zero arrears.
T04
A payment is reversed.
Review and rescoring start. The audit record stays.
T05
A scoring run fails.
The last score is marked stale. The live view still updates. No new risk_updated event fires. Service alerts remain independent.
T06
A review-case write fails.
The write retries with the same key. No duplicate review case appears.
T07
Three contacts concern one unresolved problem. Three other contacts concern separate enquiries.
The history distinguishes repeat contacts about one case from contacts about separate cases. A case state change alone does not count as a contact.
Deliberately not specified
Alert thresholds. The team freezes them on validation data.
Segment names. They follow inspection of the clusters.
Mortgage default prediction. This build predicts external refinancing, not failure to repay the loan.
Contact scripts and customer messages.
Fabric capacity and licences.
Full submission sections
The detail behind the specification above. Open a section to read it. Printing opens every section. Shared rules are on the overview page.
01 / Submission summary
Title: Mortgage Renewal Early Warning.
Problem: HomeBridge finds out about external refinancing only after the borrower leaves.
Solution: Fabric joins mortgage, payment, product-transfer request and servicing history with live renewal-portal events. It scores external refinancing risk at the checkpoint, 90 days before the fixed-rate deal ends. It explains each score to a servicing adviser.
Business impact: Advisers get time to arrange fixes for portal faults and review renewal needs before the borrower leaves. The 90-day lead time is a proposed target. Payment-support needs reach trained staff first.
Distinctive value: The design separates commercial loss from payment distress. A retained mortgage is not always a good customer outcome.
Scope: Fixed-rate repayment mortgage accounts, one renewal cohort, one renewal-portal fault replay and one payment-support case.
Out of scope: Lending decisions, rate changes, product recommendations and mortgage default prediction.
Form answers: The submission pack gives the text for each field of the blueprint form.
02 / Data contracts and account view
Dataset and grain
Required fields
Checks
Mortgage: one loan account and fixed-rate deal cycle.
Categories include general enquiries, complaints and billing enquiries. This is source history, not a new SharePoint review case. Reconstruct each case's resolved or unresolved status at the cutoff. Keep sensitive notes out of features. Show only routing information to authorised advisers.
Servicing contact: one customer contact linked to a source case.
Link each contact to its case and mortgage. Keep the contact date. Count each contact_id once, not each case state change. Both timestamps must be at or before the cutoff for model inputs. Quarantine unknown or conflicting case links.
Feature snapshot: one mortgage, deal cycle and cutoff time. Observed outcome: one mortgage and deal cycle, recorded separately.
Append one row per scheduled run. Never overwrite a row. An auditor can see each account's segment on any past date.
Account view
The mortgage view shows fixed-rate deal end, current terms, request status, portal faults, segment, refinancing risk score age and source evidence. It also shows the assigned review owner and payment-support priority.
Support history shows the enquiry type, contacts per case and whether each problem is resolved or unresolved.
Synthetic data
Include complete outcomes, reversals, delayed feeds and successful transfers.
Include three contacts about one unresolved problem and three contacts about separate enquiries.
Generate model outcome labels from separate hidden factors, not from the alert rule.
Label any future payment figure as an illustration. It is not an offer or an affordability decision.
03 / Architecture and interfaces
Keep the high-level design as the entry point. These four detailed views name components, stores, messages and failure paths.
Proposed implementation detail, not a deployed system. Table names and job boundaries are proposed. Tenant access and connector permissions remain unconfirmed.
Processing steps
Step 1Fabric pipelines load dated mortgage account, payment, product-transfer request and servicing exports into raw Lakehouse tables. See components
Step 2Notebooks validate keys and ledger history. They build clean account histories and frozen feature snapshots. See components
Step 3Notebooks train the renewal model and the behavioural clusters. MLflow records experiments, feature signatures and model versions. See data and evidence
Step 4Scores, segments, attributions and evidence references go to curated Gold Delta tables. A completed-run marker makes them eligible for publication. A Power BI semantic model reads completed outputs in Direct Lake mode. See components
Step 5Eventstream replays a renewal-portal software fault into Eventhouse. Each event keeps its original ID and timestamps. See components
Step 6KQL journey queries in Eventhouse find three patterns: See components
each product-transfer request's stages and portal errors in time order
days that a request remains at one stage, for example while documents are outstanding or an offer is in review
retries after a renewal-portal software error.
Step 7A Fabric pipeline copies versioned account context and completed score summaries into Eventhouse. KQL joins these copies with accepted live events. See components
Step 8A separate pipeline copies cutoff-filtered KQL journey results into Lakehouse staging tables. Notebooks combine these results with dated history. See scoring sequence
Step 9A Fabric pipeline runs scoring and segment assignment on a schedule. For the replay, the team also starts one scoring run by hand. See scoring sequence
Step 10Activator and Power Automate create an internal review case, assigned to a person, in a secured SharePoint list. See case routing
A persisted publication record keeps the same event_id on retry. Activator passes the required fields to a Power Automate custom action.
The review-case key is mortgage_id + cycle_id + action_family. A duplicate write reads the existing review case. Other write failures stay visible.
The case writer checks current payment-support needs before creating a review case. Payment-support priority does not depend on refinancing risk or loan balance.
Confirm context-copy frequency, live-view presentation and report refresh settings. The 60-second view target is not a Direct Lake guarantee.
Confirm retry limits, timeout values and exception ownership before the build. No automatic retry can bypass an eligibility check.
04 / Prediction and segments
Target
Checkpoint:deal_end_at minus 90 days.
Positive model label: confirmed external refinancing between the checkpoint and deal_end_at plus 30 days. Use known redemption reasons or verified refinance records.
Negative model label: a same-lender product transfer or continued servicing. Assign it only after the observation window ends, 30 days after deal end.
Excluded: sales, bereavement closures and redemptions with no known reason.
Features
Use product-transfer request completion, renewal-portal errors, complaint age, case category, contacts per case and case resolution status.
Support case status is resolved or unresolved at the checkpoint. A resolution recorded after the cutoff is not an input.
Derive three behavioural signals from dated history:
failed product-transfer request attempts in the last 30 days compared with the last 90 days
days that a request remains at one stage, for example while documents are outstanding or an offer is in review
support history: enquiry type, contacts per case, repeat contacts about unresolved problems and monthly contact trends.
Exclude sensitive support details, protected characteristics, names and fine-grained location. Check the remaining features for unjustified proxies.
Payment difficulty follows the payment-support policy. It is not a hidden external-refinancing outcome label.
Models and segments
Compare logistic regression and a small tree model with a product-transfer request-friction rules baseline.
Fit two to five clusters on product-transfer request and servicing features. Inspect stability and centroids before naming groups.
Fit clusters once per model release. Each scheduled run assigns accounts to those clusters, so a segment ID keeps its meaning.
Evaluation
Test on later deal cohorts. Keep their borrowers out of training.
Training outcome labels must exist before the simulated model release. Freeze thresholds on model-validation data.
Report accuracy, precision, recall, calibration and lift at ten reviews per run.
Lift compares the refinancing rate in the ten highest-scored accounts with the cohort's base rate. Accuracy alone misleads when few accounts leave.
Explanations
Store per-account feature attributions with each score. Use SHAP values for the tree model and coefficient contributions for logistic regression. They explain the score, not the borrower's motive.
05 / Alert routing and audit
Routing order
An active payment-support request goes to trained servicing staff. Commercial renewal tasks wait while the payment-support case needs review.
A verified renewal-portal software fault goes to technical support.
An eligible external-refinancing risk candidate goes to a servicing adviser for a renewal review.
Eligibility here permits an internal review case. It does not approve a mortgage, a rate, or customer contact. A human checks contact policy and suitability before any customer-facing action.
Audit record
Every review case records evidence IDs, routing policy, assigned owner and decision. Score-based cases also record model version, run and snapshot. Record ingestion, scoring, alert and case-creation times separately where those operations apply.
Failure handling follows cases T01 to T06 above.
06 / Build plan and demo
Work package
Output
Data and replay.
Account histories, reversal fixtures, cutoff checks and the event contract.
Models and evaluation.
Classifier, clusters, rules baseline, later-cohort report with lift, and registered model.
Dashboard and action.
Power BI mortgage report (Direct Lake), segment history, sensitivity labels, payment-support-first routing, review-case writer and audit.
Demo script
Show Alex's checkpoint, deal date, evidence and proposed renewal review.
Run the KQL journey query for Alex's product-transfer request. Show the stage history behind the stalled-request signal.
Replay a renewal-portal fault and a payment-support request. Show rescoring and payment-support-first routing.
Replay the same event. Show one review case for the same key, not two.
Show Sam's completed product transfer and a reversed payment collection. Explain why neither proves mortgage default.
Show the evaluation, measured latency and limits.
Acceptance tests
The demo passes INV-1 to INV-6 and T01 to T06. It also shows these results:
Each checkpoint warning comes 90 days before deal end.
Each scheduled run adds segment rows. Earlier segment rows never change.
Every Fabric item that holds personal data carries a Purview sensitivity label.
07 / Value and controls
Value measures
Measure review effort, renewal-portal faults fixed, payment-support routing time and confirmed external-refinancing outcomes. Loan balance is exposure, not saved revenue.
Data protection
Use pseudonymous accounts and least-privilege roles. Restrict support information separately.
Exclude bank details and borrower documents.
Apply Purview sensitivity labels to the Lakehouse, Eventhouse, semantic model and report.
Before real use
Get lending, privacy and responsible-AI review. Confirm jurisdiction, contact policy and fairness checks.
Copy five answers into the form. Then upload the files in the second section.
Form
Architecture Blueprint
Idea submission
18 Oct 2026
Solution submission
6 Nov 2026
Status
Draft · not sent
The answers describe a proposal. The system is not built. The 90-day lead time and the timing targets are proposed targets, not measured results.
1 · Form answers
The boxes follow the layout of the organiser's form. Each box has a copy button. The copied text is plain text, so it pastes cleanly into the form. A red star marks a required field.
Why this form
Each box sits where its field sits on the organiser's form, so you can copy each answer to the matching field. Trade-off: the answers are short. The blueprint page gives the full detail.
2 · Architecture and design documents
The form accepts PDF, PNG, JPG, SVG, Excel, CSV, video, PPTX and DOCX files, up to 100 MB each. Upload files 1 and 2 as a minimum. Files 3 to 9 add evidence and architectural detail.
1
High-level architecturePNG or SVG
The proposed design in five zones: history, live events, scheduled scoring, review action and independent support. Files 6 to 9 expand this view.
2
Blueprint documentPDF
The full Mortgage Renewal Early Warning blueprint for the fictional mortgage provider HomeBridge. The button opens the blueprint page and the print window. Select “Save as PDF”. Printing opens every section.
3
Signals-to-action diagramPNG
An illustrative case. Three signals lead to one action, and the payment-support check runs first.
4
Checkpoint time linePNG
The checkpoint 90 days before the deal ends, and the outcome window.
5
Data contractCSV
Each dataset with its grain, its required fields and its checks. Excel opens this file.
6
Components and data movementPNG or SVG
Fabric items, storage boundaries, explicit context copies, KQL joins and the two reporting paths.
7
Data relationships and keysPNG or SVG
Snapshots, scores, model versions, segment history, publication records and review cases.
Payment-support-first review-case routingPNG or SVG
Independent service rules, review-case eligibility checks, unique case writes and visible failure handling.
Do not use the protected page URL instead of file uploads. Submission reviewers do not receive the page password. Upload the exported files.
Downloads use the light theme. Previews of files 1, 3 and 4 follow.
Preview the four detailed architecture diagrams
3 · Solution submission · 6 November
The team builds from 26 October to 6 November. Then the team sends this package.
Submission summary and architecture diagram.
Data contracts and the synthetic-data specification.
Notebooks, pipelines and KQL queries.
Registered model, model card and evaluation report.
Routing tests and audit records.
Setup instructions.
A 5–10 minute video.
Still to confirm: Power BI sharing, Power Automate licences and connector permissions. Synthetic data shows that the process works. It does not show real predictive power.
Customer Pulse 360 · Submission blueprint
Submission blueprint · Insurance · Fictional company
HavenCover
Claims recovery and renewal early warning.
Target
Checkpoint
90 days before policy expiry
Customer unit
Owner
Claims coordinator, then service adviser
Status
Proposal · not built
Hackathon proposal. Fictional business and proposed targets. No implementation results are claimed.
How one warning becomes one action
Company, customer and counterexample (illustrative)
The company and customer
HavenCover is a fictional home insurer with annual policies. A claims coordinator manages repair partners. A service adviser owns renewal reviews.
The customer unit is one policy and renewal cycle. Claims and repair jobs link to that policy without merging unrelated household members.
The problem and counterexample
Identify customer-led non-renewal risk 90 days before policy expiry. Investigate unresolved recovery problems before proposing a commercial action.
Robin's flood claim has repeated missed repair appointments and an unresolved accommodation request. Separate systems hide the continuing problem.
Casey's larger claim resolves within agreed milestones. Claim size alone does not justify the same action.
Build specification at a glance
The rules that must hold, the data shape, and the failure cases the demo must pass. Full detail is in the sections below.
Invariants
INV-1Urgent assistance routes first, whatever the churn score or premium value.
INV-2Features use only data known at the checkpoint. Both occurred_at and ingested_at must be at or before cutoff_at. A renewal quote issued after the checkpoint is excluded.
INV-3At most one open case exists per policy_id + cycle_id + action_family. One incident exists per incident_id.
INV-4Insurer withdrawal and unknown outcomes are not churn labels.
INV-5risk_updated fires only after a scoring run succeeds. A failed run leaves the last score marked stale.
INV-6The prototype changes no claim decision, premium, settlement or coverage.
Data contract
Policy
One policy and renewal cycle.
Claim
One claim state change.
Repair
One appointment or milestone change.
Service
One complaint or assistance state change.
Snapshot
One policy, cycle and cutoff.
Segment
One policy, cycle and scoring run.
Key: policy_id + cycle_id. Every event carries an event time and an ingestion time. The risk_updated event carries the snapshot, model version, score, segment, evidence IDs and score time.
Failure cases the demo must pass
ID
Case
Expected result
T01
The same event is replayed.
One policy case only.
T02
One contractor fails on several claims.
One incident, with a linked case for each affected policy.
T03
A repair job has no claim mapping.
The record goes to quarantine.
T04
The repair feed is stale, or an event is malformed.
The view flags the stale feed. The malformed event is rejected.
T05
A repair completes.
Rescoring and review start. Complaints do not close automatically.
T06
A case write fails.
The write retries. An operator sees the error.
Deliberately not specified
Alert thresholds. The team freezes them on validation data.
Segment names. They follow inspection of the clusters.
Pricing, underwriting and fraud decisions.
Contact scripts and customer messages.
Fabric capacity and licences.
Full submission sections
The detail behind the specification above. Open a section to read it. Printing opens every section. Rules for both blueprints are on the overview page.
01 / Submission summary
Title: HavenCover Home-Recovery and Renewal Desk.
Problem: HavenCover finds out that a customer is leaving only when the policy does not renew. Repair and complaint records sit in separate systems.
Solution: A Fabric solution joins policy, claim, repair and complaint history with live repair events. It predicts customer-led non-renewal 90 days before expiry. It groups policies by service experience.
Business impact: Claims coordinators get time to fix failed repairs before the renewal decision. The 90-day lead time is a proposed target. Urgent assistance never waits for a churn score.
Distinctive value: The design assesses recovery experience, not claim cost. One contractor incident links all affected policy cases without duplicate work.
Scope: Home policies with observed renewal decisions, one flood-repair story, one controlled replay and one human-approved action.
Out of scope: Underwriting, fraud detection, premium setting, claim rejection and automatic coverage changes. A risk score never blocks a claim.
The case key is policy_id + cycle_id + action_family. Each incident_id has one contractor incident with linked policy cases.
The design records ingestion, scoring, alert and case times separately. It does not claim instant scoring for each event.
04 / Prediction and segments
Target
Checkpoint:expiry_at minus 90 days.
Positive: an explicit customer-led non-renewal at that expiry. It needs a recorded renewal decision and observation through the agreed renewal-processing window.
Excluded: insurer withdrawal and closures outside customer choice.
An automatic-renewal setting does not prove a negative outcome.
Features
Use missed appointments, unresolved complaint age, repeat contacts, overdue milestones and prior service experience. Exclude claim amount from the first model.
Derive three behavioural signals from dated history:
missed appointments in the last 30 days against the last 90 days
unresolved complaint age
the trend in repeat contacts.
Use only price information available at scoring.
Models and segments
Compare logistic regression and a small tree model with a missed-milestone-plus-complaint baseline.
Fit two to five clusters on service and recovery features. Inspect separation and stability before naming groups such as smooth recovery or repair friction.
Fit clusters once per model release. Each scheduled run assigns policies to those clusters, so a segment ID keeps its meaning.
Evaluation
Test on later renewal cohorts. Keep households and shared contractor incidents apart across training and test sets where possible.
Training labels must exist before the simulated model release. Freeze thresholds on validation data.
Report accuracy, precision, recall, calibration, class counts and lift at ten reviews per run.
Lift compares the non-renewal rate in the ten highest-scored policies with the cohort's base rate. Accuracy alone misleads when few policies lapse.
Explanations
Store per-policy feature attributions with each score. Use SHAP values for the tree model and coefficient contributions for logistic regression. Show them beside the source evidence. They do not prove why a customer leaves. They do not prove that service recovery prevents departure.
05 / Alert routing and audit
Routing order
Urgent assistance has its own path. It does not depend on churn risk, premium value or a retention threshold.
An unresolved repair failure goes to the claims coordinator.
A renewal review goes to the service adviser, only after urgent assistance gets attention.
A human approves contractor escalation and customer contact.
Audit record
Each case stores policy and claim IDs, snapshot, model, evidence, promise version, incident link, owner and decision. It also stores separate operation times.
Failure handling follows cases T01 to T06 above.
06 / Build plan and demo
Work package
Output
Data and replay.
Policy and claim histories, milestone versions, contractor incidents and fixtures.
Models and evaluation.
Classifier, clusters, baseline, leakage checks, lift report and model card.
Dashboard and action.
Direct Lake recovery view, segment history, sensitivity labels, incident linking, case writer and assistance routing.
Demo script
Show Robin's checkpoint warning and unresolved recovery milestones.
Run the KQL journey query for Robin's claim. Show the missed milestones behind the score.
Replay a missed appointment. Show rescoring and a coordinator-owned case.
Replay the duplicate and a second affected policy. Show one contractor incident with separate policy cases.
Show Casey's resolved claim. Explain why claim size is not a service-failure rule.
Show urgent assistance with a low churn score. Then show the evaluation report.
Acceptance tests
The demo passes INV-1 to INV-6 and T01 to T06. It also shows these results:
Each checkpoint warning comes 90 days before policy expiry.
Every accepted repair event maps to one claim and one policy.
Each scheduled run adds segment rows. Earlier segment rows never change.
Every Fabric item that holds personal data carries a Purview sensitivity label.
07 / Value and controls
Value measures
Measure milestone review effort, confirmed repair problems, assistance routing time, case duplication and observed renewals. Premium linked to reviews is not saved revenue.
Data protection
Use pseudonymous policies and restricted role-based views.
Exclude addresses, medical data, bank details and claim documents from exports and prompts.
Apply Purview sensitivity labels to the Lakehouse, Eventhouse, semantic model and report.
Before real use
Get claims, privacy and responsible-AI review. Check proxy discrimination and service access separately from prediction quality.
01 / WorkHarbour / Field-service softwareMaintenance companies use WorkHarbour to schedule jobs and create invoices under annual contracts. Invoice failures and reopened support tickets could put renewal at risk.Explore the company, evidence, and proposed solution
The company
WorkHarbour sells cloud software to maintenance companies. Dispatchers schedule engineers. Engineers record completed jobs. Office staff create invoices.
Customers pay per field engineer under annual contracts. The subscribing company is the customer, not each engineer.
A customer-success manager owns adoption and renewal. Fewer licences affect revenue but remain a separate prediction target.
The problem statement
Find companies at risk of not renewing, about 90 days before renewal. Show evidence that supports an approved retention action.
A fictional customer, Alder Maintenance, completes fewer jobs through the software. Invoice failures and reopened tickets accompany that decline.
The manager needs to distinguish workflow failure from seasonal demand before choosing an action.
Assumed existing stack
An Azure App Service API serves the dispatcher portal and engineer app.
Azure SQL stores accounts, contracts, jobs, and invoice outcomes.
Application Insights stores workflow failures and timestamps.
A support platform exports ticket severity, resolution times, and reopen events.
A CRM stores renewal dates, account owners, and approved contact activity.
Evidence to collect
Completed jobs and active licensed seats over time, not logins alone.
Invoice failure rates, affected workflows, and linked support tickets.
Contract value, renewal date, account tenure, and observed renewal outcome.
Seasonal history and missing records that could change the interpretation.
Counterexample: another company uses the product less during its quiet season, without workflow or support problems.
Proposed solution: a renewal investigation desk
Join account, contract, product, and support records in a Fabric Lakehouse using known account IDs.
Create dated features for usage trends, workflow failures, and unresolved support problems.
Train a renewal classifier and behavioural clusters in Fabric notebooks. Record experiments with MLflow.
Show segment, risk drivers, contract value, and source evidence in a Power BI account view.
Replay a support escalation through Eventstream and Eventhouse. Refresh the score through a separate, explicit operation.
Use Activator to flag eligible accounts. Create one retention case for a manager to review.
First action: escalate the invoice incident or restore adoption before renewal. Do not assume the customer intends to switch competitors.
Investigation desk / Is the product failing, or is demand seasonal?
Illustrative patterns, not measured data. Chart heights show no numeric values. This desk does not run ML or create cases.
Alder Maintenance / 90 days before renewal
The trend gives context. Linked incidents give the manager something to investigate.
01 / Product recordCheck completed jobs, active seats, and invoice outcomes.
02 / Support recordLink the reopened ticket to the failing workflow.
03 / Contract recordCheck the renewal date, owner, and approved action.
Counterexample / A quiet season, not a broken workflow
Solid: current pattern. Dashed: seasonal comparison. Both are illustrative, with no numeric scale.
Build cost: find or generate credible account histories with complete renewal outcomes. Do not generate labels from the model's own rule.
Proof: score with only information available 90 days before renewal. Test later outcomes against a simple rules baseline.
Why lead with this: the contract gives a clear outcome. The failing workflow gives a concrete action.
01 / Submission summary
Title: WorkHarbour Renewal Investigation Desk.
Maintenance companies need reliable job and invoice workflows. A failed workflow can reduce adoption before an annual renewal.
Our proposed solution combines contract, product, and support records in Microsoft Fabric. It groups accounts by behaviour and predicts non-renewal.
The manager receives a warning 90 days before renewal, with model drivers and linked evidence. New incidents trigger a separate investigation path.
A human reviews each proposed action. The prototype demonstrates prioritisation and an auditable case, not proven retention improvement.
Distinctive value: connect a commercial warning to a repairable workflow problem. Show seasonal decline as a counterexample.
Scope: one workspace, one business, one renewal target, and one controlled event replay. Exclude automatic discounts and customer messages.
Require occurred_at and ingested_at at or before cutoff_at. Report missing feeds instead of assuming zero incidents.
The customer view shows contract dates, value, segment, score timestamp, model version, three drivers, evidence links, and case status.
Use synthetic account histories for the first build unless approved real data exists. Include noise, seasonal demand, missing feeds, and complete outcomes.
Generate outcomes from separate latent business factors. Do not copy the alert rule into the outcome label.
03 / Proposed architecture and interfaces
Use a Fabric pipeline to load dated contract, product, and support exports into raw Lakehouse tables.
Use a notebook to validate IDs, preserve source timestamps, and create clean history tables.
Create feature snapshots and train models in Fabric notebooks. Register model signatures and versions with MLflow.
Write scores, segments, explanations, and evidence references to curated Delta tables. Publish a Power BI semantic model.
Send replayed incidents through an Eventstream custom endpoint into Eventhouse. Retain the original event ID and timestamps.
Run a separate scoring notebook for affected accounts. Publish a risk_updated event only after scoring succeeds.
Configure Activator to monitor eligible risk_updated events. Invoke a Power Automate flow that creates or updates a review case.
Historical path: exports to Lakehouse to feature snapshots to registered model to account dashboard.
Event path: incident to Eventstream to Eventhouse to scoring job to risk_updated to Activator to review case.
The first build starts the scoring notebook explicitly. Scheduled scoring is acceptable. Neither path claims per-event model inference or instant dashboard refresh.
Store cases in a SharePoint list with a unique case_key column. Power Automate handles duplicate-key responses by reading the existing case.
Use case_key = account_id + cycle_id + action_family. A notification retry must not create another case.
04 / Prediction and segmentation
Checkpoint: renewal_at minus 90 days. Predict non-renewal for that cycle using information available at the checkpoint.
Use an explicit renewal decision as the label. Missing decisions remain unknown, not churn. Confirm the outcome rule with the business.
Compare logistic regression with a small tree model. Fit preprocessing only on training data. Record parameters, dataset version, and metrics.
Use 30-day and 90-day histories for completed jobs, seat adoption, invoice failures, reopened tickets, and unresolved severity.
Keep contract value outside the prediction model initially. Use it to prioritise cases without confusing value with churn likelihood.
Fit behavioural clusters on scaled adoption and service features. Compare two to five clusters using stability, separation, and business interpretation.
Name clusters after inspecting their centroids. Proposed names include stable adoption, low adoption, and service friction. These are not measured results.
Explain scores with model contributions and source records. Contributions describe the model, not the customer's motivation.
Use later renewal cohorts for testing. Keep test accounts outside training. Exclude training labels unavailable before the simulated model release.
Freeze thresholds on validation data. Compare precision and recall at a proposed capacity of ten account reviews per run.
Live updates use a separate evaluation set. Do not describe a warning created after the checkpoint as a 90-day warning.
05 / Alert policy and failure handling
Create a review case when risk exceeds the validated threshold, evidence is current, and an owner exists.
Route invoice failures to product support with the customer-success manager. Route low adoption without incidents to an adoption review.
Record received_at, scored_at, alerted_at, case_created_at, model_version, snapshot_id, evidence IDs, owner, and decision.
Proposed states are New, Reviewed, Action approved, In progress, Resolved, and Closed. Only a human approves customer contact.
Quarantine unknown account IDs. Reject malformed events. Flag stale scores. Send failed case writes to a retry queue with an operator-visible error.
A recovery event updates the evidence and requests rescoring. It does not erase the case history or prove future renewal.
06 / Build plan, demo, and acceptance tests
Stage
Deliverable
Before idea submission: October 18.
Confirm tenant access, dataset basis, contract definition, and scenario choice.
October 26-28.
Validated history tables, feature contract, and replay fixtures.
October 29-November 2.
Baseline, classifier, clusters, registered model, and later-cohort evaluation.
November 3-5.
Account view, Activator rule, unique case writer, and integration evidence.
November 6.
Reproducible submission package and a 5-10 minute video.
Build the dashboard against agreed score fixtures while ML work continues. Replace fixtures with registered-model output before recording the final demo.
Show Alder's dated account view and renewal checkpoint. Explain the evidence and segment.
Replay an invoice incident. Show ingestion, explicit rescoring, the alert, and one assigned case.
Replay the same event again. Show that the case count remains one.
Show the seasonal account. Explain why lower usage alone does not justify the same action.
Show evaluation results, latency measurements, and limits. Distinguish synthetic mechanics from commercial evidence.
All scored rows link to one account, cycle, snapshot, and model version. Unknown IDs produce no retention alert.
Every checkpoint feature passes both timestamp checks. The reported checkpoint warning precedes renewal by at least 90 days.
Report precision, recall, class counts, and a rules baseline. Do not claim superiority if the model loses.
The duplicate replay creates exactly one case. A failed case write appears as a failed operation, not success.
Proposed targets: event visibility within 60 seconds and case creation within five minutes after successful scoring. Measure both separately.
07 / Value, controls, and submission package
Measure review effort, confirmed workflow incidents, and annual contract value associated with eligible cases. Value at risk is not saved revenue.
Use pseudonymous IDs and least-privilege workspace roles. Exclude personal messages and credentials from exports. Apply approved data-retention periods.
Capacity, Power BI sharing, Power Automate licensing, and connector permissions remain unconfirmed. Test the complete action path before promising it.
If the SharePoint connector fails, show a local review record and identify the missing integration. Do not claim that SharePoint created a review case.
Submit this proposal, architecture, dataset provenance, reproducible notebooks, model versions, evaluation report, action audit, setup instructions, and video.
Confirm organiser fields, team names, and deadline timezone before submission. This blueprint is a proposed design, not a completed entry.
02 / HearthNet / Household broadbandHouseholds pay monthly for broadband under fixed-term contracts. Repeated evening outages and an unresolved complaint could threaten renewal, even when the network looks healthy.Explore the company, evidence, and proposed solution
The company
HearthNet provides household broadband. Customers pay monthly under fixed-term contracts.
Network operations monitors service health. Support handles complaints. A retention adviser manages eligible contract reviews.
The customer unit is a household subscription. Cancellation or switching at contract expiry counts as churn.
The problem statement
Identify household subscriptions at risk of cancellation or switching, about 90 days before contract expiry.
A fictional household repeatedly loses evening service. Its complaint remains unresolved as contract expiry approaches.
The adviser needs household evidence, not a network average, before recommending a service fix or eligible plan review.
Assumed existing stack
Network monitoring emits device availability, outage, and recovery events.
A service inventory maps a household subscription to its current device and service line.
A billing database stores plans, price changes, contract dates, and cancellation outcomes.
A CRM and support system store complaints, engineer visits, and contact eligibility.
Evidence to collect
Outage frequency, duration, recovery, and affected subscription IDs.
Unresolved complaints, repeat contacts, and failed service visits.
Price changes, contract expiry, and observed cancellation or switching outcomes.
Device-to-subscription mappings valid at each event timestamp.
Counterexample: a regional outage resolves promptly. The household reports no continuing problem and has no unresolved complaint.
Proposed solution: a household service-recovery desk
Join billing, service inventory, and support history in a Fabric Lakehouse.
Aggregate outages per subscription in Eventhouse. Preserve event-time mappings and recovery events.
Train a contract-expiry classifier and service-experience clusters in Fabric notebooks. Record experiments with MLflow.
Show risk drivers, recent outages, unresolved complaints, and plan eligibility in Power BI.
Replay another outage through Eventstream. Refresh the risk score separately and record both operation times.
Use Activator to flag an eligible case. Route service failures to operations and eligible plan reviews to the retention adviser.
First action: investigate the recurring service fault. Offer a plan review only when the household meets eligibility rules.
Service desk / What does the network average hide?
Illustrative service timeline, not telemetry. The bands show event sequence, not outage duration or measured availability.
One household / Repeated evening failures
Markers represent outages. Map each event to the household subscription at the event time.
01 / Service inventoryCheck which device served this subscription at each event time.
02 / Outage historyCheck repeated faults and recovery events, not only network averages.
03 / Support and billingCheck complaint status, contract expiry, and plan eligibility.
Counterexample / One regional incident with recorded recovery
An outage alone is incomplete evidence. The recovery record changes the investigation.
Build cost: network, household, and service records make telemetry and identity matching more complex.
Proof: test contract-expiry outcomes using information available 90 days earlier. Prevent one regional incident from creating duplicate household cases.
Choose this when: the team has suitable network data and understands device-to-household mapping.
01 / Submission summary
Title: HearthNet Household Service-Recovery Desk.
Network averages can hide repeated faults at one household. Separate billing and support records make those faults harder to investigate.
Our proposed solution combines subscription, network, billing, and complaint history in Microsoft Fabric. It predicts contract-expiry churn and groups subscriptions by service experience.
A retention adviser sees a warning 90 days before expiry, with outage evidence and model drivers. New faults create human-owned investigation cases.
The prototype demonstrates service recovery before a commercial offer. It does not prove that an intervention prevents cancellation.
Distinctive value: preserve household identity at the event time. Distinguish recurring faults from a resolved regional outage.
Scope: one subscription cohort, one expiry target, one regional incident, and one recurring household fault. Exclude automatic credits and plan changes.
Use only information recorded by the cutoff. Keep future cancellations and later recoveries outside checkpoint features.
The subscription view shows contract expiry, plan eligibility, household outage history, complaints, segment, score age, evidence, and assigned case.
Use synthetic network and contract histories unless approved real data exists. Include device replacements, missing recovery events, delayed arrivals, and regional incidents.
Generate retained and cancelled outcomes from separate latent factors. Add realistic noise instead of copying outage thresholds into labels.
03 / Proposed architecture and interfaces
Load dated billing, inventory, and support exports into a Fabric Lakehouse with a pipeline.
Validate subscription keys and assignment intervals in a notebook. Preserve historical mapping versions.
Send replayed outage and recovery events through an Eventstream custom endpoint into Eventhouse.
Aggregate outage counts and durations by subscription using event-time mappings. Preserve incident references for investigation.
Transfer dated aggregates into Lakehouse feature snapshots through an explicit notebook job.
Train and register models with MLflow. Write scores, segments, and explanations to curated Delta tables.
Publish a Power BI subscription view. Send successful scoring results as risk_updated events to Eventstream.
Use Activator to detect eligible alerts. Invoke Power Automate to create or update a SharePoint review case.
Historical path: billing, inventory, and support to Lakehouse to dated features to registered models to subscription view.
Event path: network event to Eventhouse to subscription aggregate to explicit rescoring to Activator to case.
Run the first scoring notebook explicitly. Record ingestion, aggregation, scoring, and dashboard refresh times separately.
SharePoint enforces a unique case_key. Use subscription_id + cycle_id + action_family for household review cases.
Keep one operations incident per incident_id. Link affected household cases to that incident instead of creating duplicate operations incidents.
Power Automate reads the existing case after a duplicate-key response. Other write failures remain visible and enter a retry queue.
04 / Prediction and segmentation
Checkpoint: expiry_at minus 90 days. Predict explicit cancellation or switching for that expiry cycle.
Exclude relocations and mandatory disconnections from the initial target. Report this scope restriction rather than treating every closure as preventable churn.
Compare logistic regression with a small tree model. Fit preprocessing on training data and register model signatures with MLflow.
Features include 30-day outage count, observed downtime, recurring evening faults, unresolved complaint age, failed visits, tenure, and known price changes.
Missing recovery records produce an incomplete-duration flag. Do not invent recovery times or use later recovery information at the checkpoint.
Cluster subscriptions using scaled service and support features. Compare two to five clusters for stability, separation, and useful interpretation.
Possible segment names include stable service, recurring local faults, and complaint friction. Name segments only after inspecting fitted clusters.
Use later expiry cohorts for testing. Keep test subscriptions outside training. Remove regional incidents shared across training and test cohorts.
Exclude training labels unavailable at the simulated model release. Freeze thresholds on validation data before the final test.
Report precision and recall at a proposed capacity of ten household reviews per run. Compare against an outage-plus-complaint rules baseline.
Model contributions explain the prediction. Outage records support investigation. Neither establishes the household's reason for switching.
Evaluate live rescoring separately. A new warning inside the final 90 days cannot count as a checkpoint warning.
05 / Alert policy and failure handling
Create a review case when risk exceeds the validated threshold, the subscription mapping is valid, and current evidence supports investigation.
Route continuing faults to network operations. Route eligible plan reviews to the retention adviser after service evidence receives review.
Check contact eligibility before outreach. A risk score cannot authorise a discount, credit, or plan change.
Store snapshot_id, model_version, mapping_version, evidence IDs, received_at, scored_at, alerted_at, case_created_at, owner, and human decision.
Use New, Reviewed, Action approved, In progress, Resolved, and Closed states. Preserve the case audit after recovery.
Quarantine overlapping inventory intervals. Flag stale feeds. Retain late events for correction without rewriting earlier evaluation snapshots.
A resolved regional outage does not automatically create a recurring-fault case. An existing case receives recovery evidence and human review.
Historical inventory, network replay, interval checks, and subscription aggregates.
October 29-November 2.
Classifier, clusters, baseline, leakage checks, and registered models.
November 3-5.
Subscription view, Activator path, unique case writer, and recovery tests.
November 6.
Submission package and a 5-10 minute video with measured evidence.
Agree score and event contracts first. Build dashboard fixtures in parallel, then replace them with registered-model output.
Show one household's checkpoint warning, expiry date, recurring faults, and unresolved complaint.
Replay an evening outage. Show its historical device mapping and explicit scoring job.
Show the Activator alert and assigned case. Replay the same event and check the case count.
Show a resolved regional outage. Explain recovery and the shared operations incident.
Show model evaluation, missing-data handling, separate latency measurements, and commercial limits.
Every accepted event maps to exactly one subscription at its event time. Ambiguous mappings create no retention case.
Duplicate outage messages do not increase outage count or create duplicate cases.
Checkpoint inputs contain no future recovery, complaint resolution, or cancellation information.
Report checkpoint lead time, precision, recall, class counts, cluster profiles, and baseline results.
One regional incident creates one operations incident. Distinct affected subscriptions can retain separate linked review cases.
Proposed targets: event visibility within 60 seconds and case creation within five minutes after successful scoring.
Case-write failures remain visible. Recovery preserves the audit. It does not prove that the intervention prevented cancellation.
07 / Value, controls, and submission package
Measure investigation effort, confirmed recurring faults, case duplication, and monthly subscription value associated with eligible reviews.
Do not multiply monthly value into claimed savings. Proving improved retention requires real interventions and a comparison group.
Use pseudonymous subscription and device IDs. Exclude addresses and browsing history. Restrict household evidence to authorised workspace roles.
Confirm Fabric capacity, Power BI sharing, connector permissions, and Power Automate licensing before the build.
The main risk is historical identity quality. If valid device mappings are absent, restrict the dataset to verified subscriptions.
If the SharePoint connector fails, show a local review record and label the missing integration. Do not claim that SharePoint created a review case.
Submit this proposal, mapping contract, architecture, data provenance, reproducible notebooks, model versions, evaluation, case audit, setup instructions, and video.
Confirm organiser fields, team names, and deadline timezone. This page is a proposed blueprint, not an implemented service.
03 / PantryPaws / Repeat-purchase retailCustomers return to PantryPaws when they need more pet supplies. A purchase gap after delivery trouble needs a different response from a longer gap after buying a larger pack.Explore the company, evidence, and proposed solution
The company
PantryPaws sells pet food and other replenishable supplies online. Customers return when they need more supplies.
The company earns revenue per order, not through an annual renewal contract.
A customer-care lead fixes delivery problems. A retention specialist manages eligible replenishment reminders.
The problem statement
Find repeat customers at risk of inactivity beyond an agreed repurchase window. Separate normal purchase gaps from service-related warning signs.
A fictional customer, Morgan, regularly buys pet food. A late delivery prompts a complaint, and the next expected order does not arrive.
No purchase does not prove that Morgan chose a competitor. The team needs context before contact.
Assumed existing stack
Shopify stores customer accounts, orders, products, and refunds.
A warehouse system and carrier feeds record dispatch, delivery failures, and delivery completion.
A support platform stores complaints and resolution history.
An email platform stores contact consent, reminder history, and suppression rules.
Evidence to collect
Purchase intervals, product categories, basket value, and changes in purchase frequency.
Returns, refunds, delayed deliveries, and unresolved complaints.
Customer IDs, contact consent, open cases, and previous retention actions.
Full observation periods that distinguish inactivity from outcomes the dataset cannot yet show.
Counterexample: a customer buys a larger pack and returns later. The longer gap has no associated delivery or support problem.
Proposed solution: a replenishment and service-recovery desk
Join orders, delivery records, support history, and contact eligibility in a Fabric Lakehouse.
Agree the inactivity definition before training. Calculate purchase intervals and create dated features.
Train an inactivity classifier and purchase-behaviour clusters in Fabric notebooks. Record experiments with MLflow.
Show purchase rhythm, risk drivers, delivery evidence, and contact eligibility in Power BI.
Replay a delivery complaint through Eventstream and Eventhouse. Refresh the risk score as a separate operation.
Use Activator to flag an eligible case. Let a human choose service recovery or a replenishment reminder.
First action: fix the delivery problem. Do not send a sales reminder while an unresolved complaint needs attention.
Purchase desk / A service problem, or a larger pack?
Illustrative purchase sequence, not order data. Spacing shows relative sequence, not measured days or a churn probability.
Morgan / The expected repeat order is absent
Filled circles: purchases. Dashed circle: expected purchase. The complaint changes which action makes sense.
01 / Order historyCheck purchase intervals, product category, and pack size.
02 / Delivery and supportCheck delivery completion and complaint resolution.
03 / Contact eligibilityCheck consent, open cases, and earlier retention actions.
Counterexample / More supplies mean a longer purchase gap
Circle sizes distinguish pack types only. No size ratio or purchase interval represents a measured value.
Build cost: inactivity has several possible explanations. A 90-day warning is harder to check without a fixed renewal date.
Proof: define the inactivity checkpoint. Evaluate features available 90 days before that checkpoint, with full later outcome windows.
Predicting no purchase within the next 90 days does not prove 90 days of advance warning.
Choose this when: suitable repeat-order data exists and the team can defend its inactivity definition.
01 / Submission summary
Title: PantryPaws Replenishment and Service-Recovery Desk.
Repeat customers buy supplies at different intervals. Delivery problems can interrupt purchases, but larger packs can also explain longer gaps.
Our proposed solution combines order, delivery, support, and contact records in Microsoft Fabric. It groups customers by purchase behaviour and predicts inactivity.
The retention specialist sees dated risk scores, model drivers, and source evidence. New delivery complaints trigger a separate investigation path.
A human chooses service recovery or an eligible reminder. The prototype does not send customer messages or claim improved retention.
Distinctive value: explain a purchase gap before recommending contact. Compare delivery failure with a larger-pack counterexample.
Scope: repeat pet-food customers, one inactivity definition, one delivery replay, and one human-owned case.
Freeze the target date before scoring. Exclude customers whose later observation window is incomplete.
The customer view shows purchase rhythm, pack size, delivery evidence, complaint state, segment, score age, contact eligibility, and case status.
Use synthetic histories unless approved real data exists. Include irregular intervals, larger packs, seasonality, consent changes, and missing delivery records.
Generate outcomes from separate latent demand and service factors. Do not define synthetic churn directly from the alert rule.
03 / Proposed architecture and interfaces
Load dated order, delivery, support, and contact exports into raw Fabric Lakehouse tables.
Validate keys and reconstruct source histories in a notebook. Create clean customer and order tables.
Create dated feature snapshots and outcome tables. Train and register models with MLflow signatures and versions.
Write scores, segments, explanations, and evidence references to curated Delta tables. Publish a Power BI customer view.
Replay delivery complaints through an Eventstream custom endpoint into Eventhouse.
Run an explicit notebook to update affected features and scores. Publish risk_updated only after successful scoring.
Use Activator to monitor eligible risk_updated events. Invoke Power Automate to create or update a SharePoint review case.
Historical path: exports to Lakehouse to dated features to registered model to customer view.
Event path: complaint to Eventstream to Eventhouse to explicit rescoring to Activator to review case.
The first build starts scoring explicitly. Record event arrival, score completion, alert delivery, and dashboard refresh as separate operations.
Use a unique SharePoint case_key: customer_id + anchor_order_id + action_family. Duplicate delivery messages must not create another case.
Power Automate reads the existing record after a duplicate-key response. Other failures enter a retry queue with an operator-visible error.
04 / Prediction and segmentation
Proposed target: no completed repeat order within 180 days after an eligible anchor order. This defines inactivity, not proven customer loss.
Checkpoint: anchor order plus 90 days. The frozen inactivity date is another 90 days later.
Score only customers without a repeat order by the checkpoint. A completed repeat order before the inactivity date gives a negative label.
No repeat order through day 180 gives a positive label only when source coverage reaches that date. Otherwise, the outcome remains unknown.
Use one eligible anchor per customer in each evaluation cohort. Prevent overlapping windows from counting the same inactivity episode repeatedly.
The 180-day window is a design assumption. Confirm category suitability before submission. Test 150-day and 210-day definitions as sensitivity checks.
This design measures warning before an inactivity threshold. It cannot establish warning before the customer's unobserved decision to leave.
Compare logistic regression with a small tree model. Fit preprocessing only on training data. Register the selected model and feature signature.
Features include historical purchase intervals, pack size, order frequency, refunds, delivery delays, complaint age, and category seasonality.
Calculate historical purchase intervals using orders available by the cutoff. Do not use the next order to explain an earlier score.
Fit clusters on scaled purchase and service features. Compare two to five clusters using stability, separation, and business interpretation.
Inspect cluster profiles before naming them. Possible names include regular replenishment, larger-pack purchasing, and service friction.
Test later anchor cohorts with customers outside training. Require complete outcome windows and training labels available before the simulated release.
Freeze thresholds on validation data. Report precision and recall at a proposed capacity of ten customer reviews per run.
Compare against a historical-interval rule with complaint context. Model contributions explain the score, not customer intent or intervention effectiveness.
05 / Alert policy and failure handling
Create an internal review case when risk exceeds the validated threshold, evidence is current, and an owner exists.
An unresolved delivery complaint routes to customer care first. Suppress marketing reminders while the complaint needs attention.
A reminder requires current channel consent, no suppression, and human approval. Do not treat case creation as permission to contact.
Keep service-contact policy separate from marketing consent. Confirm the applicable business and legal rules before any real communication.
Record snapshot_id, model_version, evidence IDs, consent version, received_at, scored_at, alerted_at, case_created_at, owner, and human decision.
Use New, Reviewed, Action approved, In progress, Resolved, and Closed states. Record approval without sending messages in the hackathon build.
Quarantine unknown customer or order IDs. Flag missing feeds and stale scores. Retry failed writes without creating duplicate cases.
A new order updates the customer view and requests rescoring. Preserve earlier snapshots and the case audit.
06 / Build plan, demo, and acceptance tests
Stage
Deliverable
Before October 18.
Confirm inactivity definition, source coverage, tenant access, and dataset provenance.
October 26-28.
Clean order histories, frozen target dates, eligibility changes, and replay fixtures.
October 29-November 2.
Baseline, classifier, clusters, later-cohort evaluation, and sensitivity report.
November 3-5.
Customer view, Activator path, unique case writer, and consent tests.
November 6.
Reproducible submission package and a 5-10 minute video.
Agree score and event contracts first. Build dashboard fixtures in parallel, then replace them with registered-model output.
Show Morgan's anchor order, checkpoint, frozen inactivity date, purchase history, and unresolved complaint.
Replay a delivery escalation. Show explicit rescoring, an alert, and one customer-care case.
Replay the same event. Check that the case count remains one.
Show the larger-pack customer and a suppressed contact. Explain why their proposed actions differ.
Show evaluation, sensitivity checks, measured latency, and the limits of an inactivity target.
Every score links to a customer, anchor order, snapshot, and model version.
All checkpoint inputs satisfy event-time and ingestion-time cutoffs. Future purchases appear only in outcome evaluation.
Incomplete day-180 observation produces an unknown label, never an assumed inactivity outcome.
Report checkpoint lead time, precision, recall, class counts, baseline results, and cluster profiles.
A duplicate replay creates exactly one case. Unknown identities and failed writes remain visible.
No marketing reminder receives approval without current consent. An unresolved complaint routes to service recovery first.
Proposed targets: event visibility within 60 seconds and case creation within five minutes after successful scoring.
07 / Value, controls, and submission package
Measure review effort, confirmed delivery problems, duplicate cases, and eligible customer counts. Report repeat-order value separately from claimed savings.
Use pseudonymous customer IDs. Exclude names, addresses, payment data, and message contents. Restrict exports and apply approved data-retention periods.
Confirm Fabric capacity, Power BI sharing, Power Automate licensing, connector access, and contact policy before the build.
The main risk is the target definition. If organisers require contractual churn, select software or broadband instead of disguising inactivity as renewal.
If the SharePoint connector fails, show a local review record and label the missing integration. Do not claim that SharePoint created a review case.
Submit this proposal, architecture, target definition, data provenance, notebooks, model versions, evaluation, consent tests, case audit, setup instructions, and video.
Confirm organiser fields, team names, and deadline timezone. This blueprint is a proposed design, not a completed entry.