A churn score is only useful if the account manager sees it in Salesforce.
We build forecasting, propensity and segmentation models on the data you already have in Snowflake or Databricks. Then we put the output somewhere a person will act on it, which usually means a CRM field or a service console queue.
It's statistics and machine learning aimed at forecasting and explaining business outcomes.
In practice we build demand forecasts, churn and propensity models, segmentation and anomaly detection on Snowflake or Databricks, track the experiments in MLflow and push the scores into Salesforce or Dynamics 365. We start from a question someone will act on, and check the data is good enough to answer it.
you probably need this if
Your churn model works in a notebook, but no account manager has ever seen a score.
Demand forecasts are built in spreadsheets and nobody compares them to actuals.
Marketing and service each use their own customer segments.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Advanced Analytics, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · advanced analytics3 open
openYour churn model works in a notebook, but no account manager has ever seen a score.
recurringDemand forecasts are built in spreadsheets and nobody compares them to actuals.
blockedMarketing and service each use their own customer segments.
exposure
ForecastingChurn and propensity modelsSegmentationAnomaly detectionScores back into operationsModel operations
startrehearsehandover
Frame
Prepare data
Model and test
Deploy and monitor
we are here
ready to hand over
Planners see the model forecast and their own override side by side, with accuracy…
It's on the account record, where managers already look, with a reason they can act on.
Problem framing and success measures
Feature tables in the warehouse
chapter 01 · where it hurts
Why teams reach out
Your churn model works in a notebook, but no account manager has ever seen a score.
Demand forecasts are built in spreadsheets and nobody compares them to actuals.
Marketing and service each use their own customer segments.
chapter 02 · what we change
How we solve it
Forecasting
Churn and propensity models
Segmentation
Anomaly detection
Scores back into operations
Model operations
chapter 03 · how it runs
Our approach
Frame
Prepare data
Model and test
Deploy and monitor
chapter 04 · where you end up
What changes
Planners see the model forecast and their own override side by side, with accuracy tracked for both.
It's on the account record, where managers already look, with a reason they can act on.
Problem framing and success measures
Feature tables in the warehouse
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Demand, revenue and volume forecasts with prediction intervals, compared against the simple baseline your team uses today.
Models that score accounts, members or customers, with the main drivers shown so the people using the score trust it.
We define customer and member segments from behavior and value, once. Otherwise marketing and service each end up with their own list.
We flag odd claims, transactions or usage for review, and set the thresholds by what your reviewers can actually get through.
Model outputs written to CRM fields, service queues or campaign audiences through reverse ETL or APIs.
Experiment tracking and model registry in MLflow, scheduled retraining and drift monitoring, all governed with the same access controls as the warehouse.
capability 01 / 06in production
Forecasting
Demand, revenue and volume forecasts with prediction intervals, compared against the simple baseline your team uses today.
Experiment tracking and model registry in MLflow, scheduled retraining and drift monitoring, all governed with the same access controls as the warehouse.
We pieced these together from Advanced Analytics situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
A spreadsheet demand forecast that planners override every week
composite · not a client story
Beforethe situation
Weekly demand forecasts come from a spreadsheet a former analyst built on shipment history. It ignores promotions and stockouts, so planners override most lines by hand, and nobody tracks whether the overrides are any better.
What we dothe work
We rebuild history from orders rather than shipments, so stockouts stop looking like low demand, and add price and promotion features. A seasonal naive forecast becomes the baseline. Candidate models are backtested on rolling windows, and planner overrides are logged next to the model's number.
Afterwhere you end up
Planners see the model forecast and their own override side by side, with accuracy tracked for both. Arguments about the forecast turn into a review of specific weeks and items.
case file 02
Churn scores in a Databricks table that no account manager opens
composite · not a client story
Beforethe situation
A data scientist built a churn model on Databricks last year, and scores land in a Delta table each night. Account managers live in Salesforce and have never seen them, so the model hasn't changed a single renewal conversation.
What we dothe work
We check the model still holds up on recent renewals, then add the top drivers per account as plain-language reasons. Scores and reasons sync to custom fields on the Salesforce Account through reverse ETL, and a list view ranks upcoming renewals by risk. Sales leadership agrees what each risk band triggers.
Afterwhere you end up
It's on the account record, where managers already look, with a reason they can act on. The retraining job and the sync are monitored, so a stale score raises an alert instead of quietly misleading people.
How a model's scores get from the warehouse into the CRM
Features are built from governed warehouse tables and models get trained and tracked in MLflow. A scheduled job writes scores back to tables. Reverse ETL or an API then puts them in Salesforce or Dynamics 365, which is where people act.
Feature tablesusage · tenure · claims history → Training and experiments · training data→ Scheduled scoring · fresh features
02 · Modeling
Training and experimentsDatabricks · MLflow tracking → Model registry · register model
Model registryversions · approvals → Scheduled scoring · approved version
03 · Scoring
Scheduled scoringbatch jobs · drift monitoring → CRM fields and queues · reverse ETL or API→ Campaign audiences · segments
04 · Operations
CRM fields and queuesSalesforce · Dynamics 365
Campaign audiencessegments · next best action
Read the diagram as text
Warehouse tables → Feature tables: build features
Feature tables → Training and experiments: training data
Training and experiments → Model registry: register model
Model registry → Scheduled scoring: approved version
Feature tables → Scheduled scoring: fresh features
Scheduled scoring → CRM fields and queues: reverse ETL or API
Scheduled scoring → Campaign audiences: segments
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Frame
First we agree three things with you. The decision, the person who makes it, and how success gets measured. Modeling starts after that.
step 02
Prepare data
Features built from governed warehouse tables, with gaps and leakage checked.
step 03
Model and test
Candidate models compared with a simple baseline and validated on held-out data.
step 04
Deploy and monitor
Scores delivered into operational systems, with monitoring and a retraining schedule.
you keep
What you're left with
We write these for your Advanced Analytics setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
Data scientist
Analytics engineer
Machine learning engineer
BI developer
Statistician
due diligence · advanced analytics
Questions to ask any partner, including us.
Put these to anyone bidding on your Advanced Analytics work. The ones who've done it answer differently from the ones who've read about it.
Q1
What baseline will the model have to beat, and will you tell us if it doesn't?
A naive forecast or a simple rule is surprisingly hard to beat. Without one to compare against, an accuracy number doesn't tell you whether the model earns its keep.
Q2
How will you keep information from after the outcome out of the training data?
Features built from fields updated after the event, such as a closed-lost reason or a final claim amount, make a model look excellent in testing and useless in production.
Q3
Once this is live, where does the output appear, in which field, screen or queue? Whose work changes because of it?
Models that live in a notebook or a separate dashboard rarely get used. The delivery point and the person acting on it should be agreed before modeling starts.
Q4
How will we know the model has gone stale?
Price changes, new products and shifts in customer mix degrade models quietly. Drift monitoring and a retraining trigger belong in the first build.
Q5
Can you explain a single prediction to the person who has to act on it?
Planners and account managers ignore scores they can't explain. Per-record drivers also expose a model that has learned something wrong.
01How much data do we need?
It depends on the question. A churn model can't learn much from a handful of past churn events, and a forecast needs enough history for seasonality to show. We check this in the first weeks and tell you plainly if the data isn't there yet.
02Snowflake or Databricks for machine learning?
Both run Python and can train models next to the data. Databricks has the longer track record with Spark and MLflow. Snowflake suits teams that mostly work in SQL. In practice we build on whichever platform you already pay for.
03Is this the same as your AI and ML practice?
They overlap at the edges. Here it's analytics on structured business data. Anything generative, agents, or language and vision models, goes to our AI and machine learning practice.
04How do you make sure people use the model?
By delivering the output inside the tool they already use, explaining the drivers behind each score, and agreeing with their manager how the score changes their work.
05Can you work alongside the data scientists we already have?
Yes. Often your team owns the modeling and we build what sits around it, which is the feature pipelines, deployment, score delivery and monitoring. We agree who owns each piece before work starts, so nothing falls between the two teams.
related
Often paired with
Projects on Advanced Analytics usually end up touching one of these, so they're worth a look.
