Skip to case study
Customer lifecycle intelligence · Interactive Synthetic Prototype

SignalPath

I designed SignalPath to explore how lifecycle, product, support, engagement and customer-feedback signals could support earlier human investigation of renewal risk.

Fictional B2B SaaSSynthetic dataCandidate 10 frozen experimentCase study + live AWS demo
Primary audienceCustomer Insights / CX Strategy
Secondary usersCS, Implementation, Product, Support, Education
Analytical population4,000 synthetic accounts
StatusInteractive Synthetic Prototype
60-second summary

What to know before reading the full case study.

Problem

Lifecycle, adoption, support, engagement, feedback, and renewal evidence are interpreted in separate systems.

My contribution

Designed the evidence model, synthetic-data methodology, interpretable ranking experiment, responsible-use controls, and browser experience.

Key deliverables

Case study, frozen Candidate 10 experiment, interactive prototype, and a separate AWS demo with a read-only API.

Outcome status

Working synthetic case study and live demo with fictional customer records.

Demonstrates

Customer-journey analysis, analytics, explainable modeling, responsible AI, UX design, API integration, and technical implementation.

Business problem

Customer evidence is distributed across the lifecycle.

Lifecycle progress, product adoption, support friction, communications, education, customer feedback and renewal context are often interpreted in separate systems. SignalPath explores how those signals can be brought into one evidence trail without turning a predictive score into an automatic customer treatment.

Core question

What is happening across the customer lifecycle, who is affected, why is it happening, and what should the organization investigate next?

Fictional scenario

MeridianLoop, a configurable workflow SaaS company.

The design scenario uses a fictional mid-market and enterprise B2B SaaS company with annual subscription contracts, implementation/onboarding work, named Customer Success coverage and a full path from sale through renewal and expansion. No employer, client or customer data is used.

Sale
Implementation
Onboarding
Activation
Adoption
Value realization
Renewal
Expansion
Cross-functional evidence

Journey first, prediction second.

The experience deliberately starts with systemic lifecycle patterns, touchpoint response and segment differences before moving to an individual account. Observed evidence, model contribution, counter-signals, data quality and human interpretation are kept separate.

PatternWhere is friction accumulating?
SegmentWhich populations differ?
AccountWhat evidence deserves review?
Plain-language terms

How to read the analytical language in this project.

Lifecycle evidence
Information showing where a customer is in the relationship and what has happened so far.
Eligible renewal snapshot
A fixed view of an account 120 days before a contractual renewal, using only information available at that time.
Censored outcome
A renewal whose result is not yet observable. It is excluded instead of being incorrectly counted as retained.
Risk ranking
A relative ordering used to decide what deserves human review first, not a precise probability that an account will leave.
Calibration
How closely model scores align with observed synthetic outcomes. Imperfect calibration is why exact-looking probabilities are not shown.
Model contribution
How a signal influenced the model’s ranking within this experiment. It does not prove that the signal caused the outcome.
Synthetic-data design

4,000 accounts over 24 months, generated locally.

The development population is entirely synthetic. Renewal opportunities originate from actual synthetic contract boundaries. The prediction point is 120 days before contractual renewal and the feature observation window is the trailing 12 months ending at that point. Accounts without an observable eligible outcome are censored rather than treated as retained.

Design elementCandidate 10 setting
Primary outcomeLogo churn / non-renewal
Secondary outcomeContraction / downgrade, modeled separately
Designed prevalenceApproximately 15%; synthetic design choice, not an industry benchmark
Public account sample60 curated fictional profiles; not statistically representative

The generated development data, model matrix, partitions and raw prediction snapshots remain local and are not part of the public prototype.

Predictive-model methodology

An interpretable ranking baseline, with visible limitations.

SignalPath uses logistic regression to rank eligible accounts by relative non-renewal risk using only information available at the prediction point. Raw feedback text and the separate implementation/adoption rule scores are excluded from the baseline model.

Final-test measureCandidate 10
Eligible accounts410
ROC-AUC0.647
PR-AUC0.301
Precision at frozen 20% setting28.7%
Recall at frozen 20% setting42.9%
Accounts flagged94
Retained accounts also flagged67
Churn events missed36
Why the interface shows rank and band instead of an exact probability

Calibration is imperfect. Candidate 10 is useful as a prioritization experiment, not as a precise individual churn probability or autonomous prediction system.

Invalidated-candidate lessons

Validation failures shaped the final analytical controls.

Earlier synthetic candidates were deliberately invalidated when distribution drift, lifecycle sequencing, pre-activation production usage and renewal-eligibility defects appeared. Candidate 10 carries those lessons forward through stronger fixtures, relationship-aware intervals, contract-authoritative renewal boundaries and repeated feature-lineage checks. Earlier candidates' model metrics were not reused to optimize Candidate 10.

UX decisions

Pattern → journey → segment → account → intervention → validation.

The prototype is not structured as a generic executive dashboard or CRM. Portfolio Pulse surfaces lifecycle conditions; Journey Explorer connects touchpoints to lifecycle stages; Segments & Signals combines quantitative and qualitative evidence; Account 360 creates a deliberate boundary between pre-prediction evidence and later outcomes; Intervention Lab supports hypotheses only; Model Quality makes false positives, false negatives, calibration and segment suppression visible.

Responsible use

Human review is a product requirement, not a disclaimer.

  • Renewal risk is a relative band and Candidate 10 global percentile, never an exact individual churn probability.
  • Model contributors describe conditional model behavior and are not causal drivers.
  • Implementation risk is shown as transparent status and drivers, not a calibrated score.
  • Adoption risk keeps risk drivers, protective signals and data sufficiency separate.
  • Segment performance is suppressed below 40 total examples, 8 churn events and 20 retained examples.
  • Intervention scenarios are hypothetical model responses and cannot initiate customer treatment.
Demo architecture

A static case study with a separate serverless live demo.

The case study remains a static portfolio page. Its companion demo uses semantic HTML, CSS, and vanilla JavaScript served from the existing S3 and CloudFront site, then calls a public GET-only Amazon API Gateway endpoint backed by a Python 3.12 AWS Lambda function.

Frontend

Responsive browser interface with filters, an account-evidence table, and accessible account-detail dialogs.

API and compute

API Gateway routes summary, account-list, account-detail, health, and model-reference requests to one Lambda function.

Data

A bundled read-only SQLite file contains 4,000 fictional accounts and precomputed reference_v1.1.0-logistic scores. No managed database or live model training is used.

Operational controls

Site-restricted CORS, GET-only routes, request throttling, CloudWatch logs, and alarms support a small public demo.

Keep the two experiments separate

The Candidate 10 metrics in this case study belong to the frozen local analytical experiment. The live demo is a separate deployed implementation with newly generated synthetic data and its own model artifact; its scores and metrics are not Candidate 10 results.

Lessons learned

The hard part is not producing a risk number.

The stronger portfolio evidence comes from defining eligibility correctly, preventing leakage, making missingness explicit, comparing a model with simple operating rules, exposing capacity tradeoffs and building an interface that keeps observed evidence separate from predictive interpretation.

Try the live demo

The companion build turns the case-study concepts into a live customer-lifecycle investigation backed by a read-only AWS API. All organizations and customer records are fictional and synthetic.

Portfolio search

Find projects, capabilities, and experience.

Search across the complete portfolio.