Customer Intelligence & Segmentation

CUSTOMER INTELLIGENCE & SEGMENTATION Segment your book.

От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноМожет изменять данные

Что умеет

  • Customer Tiering: Scores a customer book of 500 transaction rows OR FEWER into A/B/C/D tiers. Send the rows directly; this server runs the survival model (BG/NBD), spend model (Gamma-Gamma), tier migr
  • Customer Tiering Get Engine: For books LARGER than 500 transaction rows. Returns a complete, runnable Python script that scores the book into A/B/C/D tiers with survival modelling (BG/NBD), spend mode

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

CUSTOMER INTELLIGENCE & SEGMENTATION

Segment your book. Predict what each customer does next. Price it in dollars.

Most tools sold as "customer intelligence" are descriptive segmentation with a better chart — they tell you what your customers already did. This one segments your book, forecasts what each customer will do next, and attaches a dollar figure with a confidence range to every forecast.

Input: three columns — customer_id, date, amount. Works from Excel, Salesforce, HubSpot, Zoho or any accounting export. No integration project.

Full results in under two minutes at any book size, on SOC-compliant infrastructure. Free while in early access.

SEGMENTATION IS THE MAP. INTELLIGENCE IS THE DECISION.

The segmentation layer tells you who your customers are, grouped so you can act: A/B/C/D tiers, behavioural cells, revenue concentration, named buckets like Champions and At-Risk. It looks backward.

The intelligence layer tells you what each one does next and what it's worth: retention probability, predicted lifetime value, migration risk, value-at-risk, contact uplift, total book exposure. It looks forward.

Both refresh nightly.

A label is a classification, not a decision — which is why CRM tier fields sit unused in most companies that have them. The difference in practice:

Segmentation says: "Acme is an A-account."

Intelligence says: "Acme is worth $60,000/yr, its purchase cadence has broken, lapse risk this quarter is 35%, that's ~$21,000 at risk ($16,000–$27,000, 90% CI), and contact this week recovers an expected $14,000."

Only one of those changes what someone does on Monday.

FOR THE C-SUITE — CEO, CFO, FOUNDER

The problem: "How much revenue is at risk this quarter?" is assembled by hand, a month stale, and nobody can reconstruct how it was calculated. Concentration risk stays invisible until it detonates. Predictive scoring that would answer it sits behind enterprise editions and a data-science setup — or a $90,000–$130,000 analyst who still can't recompute the book nightly.

One number for the board, with its working attached. "$340,000 at risk across 23 neglected accounts. $520,000 of upgrade upside in 41 B-accounts." Every dollar traces to a named customer, a named model version, and a training date.

Concentration health as a tracked metric. Revenue concentration alongside the tier split, so "we're too dependent on our top accounts" becomes a number with a trend line.

Forward-looking, not backward-looking. Tiers are assigned on predicted future value, not last year's invoices. Who will be cream, not who was.

Numbers built to survive being wrong. Every figure ships as a range with real confidence — "~$42,000 at risk ($31,000–$54,000, 90% CI)" — never a bare point estimate. A manager shown a confident number who watches the account churn anyway stops trusting every number you've shown them. A range plus a reason survives the miss.

Procurement-ready. SOC-compliant infrastructure and controls. Consent capture, retention policy and delete-on-request built in for GDPR and DPDP-style requirements.

Free while in early access. Full product, unlimited book size, no card, no seat count, no feature gating. Pricing arrives later, with advance notice.

FOR VPs — SALES, REVOPS, CUSTOMER SUCCESS

The problem: Reps work the accounts they like, not the accounts that move the number. Segments don't change behaviour. The highest-leverage moment — a customer migrating between segments — is invisible until the revenue chart shows it a quarter later. And when finance asks whether outreach actually retains revenue, you have anecdotes.

A daily queue ranked by money, not by segment. The most important design decision in the product. An A-account that stays loyal regardless has near-zero uplift and does not belong at the top of anyone's call list. A B-account a single call would save belongs at the top. Segment-ranked queues systematically spend your team's best hours on accounts that were never going anywhere.

Migration watched nightly. The whole book recomputes overnight and alerts on slips and jumps. That alert list is the morning queue, delivered into Teams or Slack — not another tab nobody opens.

Fast enough to use live. A full rescore returns in under two minutes at any book size, so a rep can pull a fresh read mid-pipeline-review.

Growth targeting, not just churn defence. Surfaces which B-accounts are most likely to reach A if touched — and the same comparison is your proof to finance that coverage works.

Explanations reps believe. Every assignment returns its full reasoning trace, model version and training date. A rep who reads "recency collapsed from 5 to 2 in 60 days" picks up the phone. A rep handed an opaque score ignores it, and the rollout dies quietly.

Book and territory exposure on tap for QBRs, headcount cases and comp design — computed identically every quarter, so the trend is real.

THE TOOLSET

score_customer_book — the full segmented ledger across the book

watch_migrations — who moved overnight, which becomes today's queue

contact_uplift — who to call first, ranked by dollars

rank_uplift_targets — which B-accounts can be grown into A's

value_at_risk — what neglect costs on this account

book_exposure — the number you report upward

explain_tier — why, auditable and versioned

predict_customer_value — expected future spend over a horizon

data_quality_report — dedupe and gap detection before scoring

FOR AGENT BUILDERS — DEVELOPERS, ISVs, CONSULTANTS

The problem: An LLM cannot fit a survival model. It ranks a CSV once, plausibly, and is wrong in ways nobody catches — ask twice, get two answers. Ship that to a client and you own the outcome. Meanwhile "the model said so" ends the conversation the moment a client asks why an account scored the way it did.

Nine deterministic tools over a standard MCP interface. Same input, same model version, same answer, every time. Structured outputs built for an agent to consume, not a human to squint at.

Production-hardened statistical modelling, not a thin wrapper around an open-source package. This class of model fails in quiet, non-obvious ways as data gets thin or unusual; ours is instrumented against that and refuses with a reason code rather than returning a confident number your client discovers is nonsense in front of their board.

Everything versioned. Model version and training date on every response, plus a full reasoning trace. Reproducible and defensible six months later.

Cross-source by design. CSV/XLSX first, so you can demo without an OAuth dance, with CRM and ERP connectors as they mature. Native CRM scoring only ever scores its own CRM; real businesses keep data in three places.

Confidence intervals as first-class output. If your agent recommends actions, you need to know when the model is guessing — and so does whoever receives the recommendation.

Sub-two-minute response at any book size, independent of customer count. Call it inside an agent loop instead of building a job queue, a polling endpoint and a callback around it.

SOC-compliant infrastructure and controls. If you're embedding this in something you sell, your customer's security questionnaire is a form you fill in, not a project you run.

For consultants: run multiple client books, white-label the reports, repeat the engagement — score the book, present the exposure, run the queue, show the migration delta at the next review. Free, no cap on books.

WHERE THIS SITS IN YOUR STACK

Not a CDP. No identity resolution, no event-stream ingestion, no profile store. It reads transactions and returns decisions.

Not a CRM replacement. Your CRM stays where it is. This reads from it and pushes decisions into your team's workflow.

Not a BI tool. BI describes what happened and leaves interpretation to you. This forecasts what happens next and prices it.

Not marketing automation. It tells you who to reach and what reaching them is worth. Sending is somebody else's job.

The honest one-liner: a predictive segmentation and account-prioritisation engine sitting between your transaction data and your team's daily work.

GET STARTED

Export customer_id, date, amount. Run the data quality check, score the book, pull book exposure, then turn on migration watch so the nightly recompute becomes tomorrow's queue.

Each step returns in under two minutes, whatever the size of your book. Free while in early access, with no customer limit.

Список инструментов сервера (2)

Технические названия из tools/list. Нужны только разработчикам.

customer_tieringScores a customer book of 500 transaction rows OR FEWER into A/B/C/D tiers. Send the rows directly; this server runs the survival model (BG/NBD), spend model (Gamma-Gamma), tier migration, money layer and decision cards, and returns the full result including a per-customer ledger with explanation traces. For books LARGER than 500 rows use customer_tiering_get_engine instead — sending thousands of rows as tool arguments is slow and risks truncated JSON. Optionally accepts rep_contacts, which lets the money layer learn contact uplift from data rather than assuming it. Customer identifiers are CLEANED HERE before scoring: capitalisation, spacing, punctuation, legal-suffix and word-order variants (ACME PVT LTD / Acme Pvt. Ltd. / Acme Private Limited) are merged into one account by rule, so send the values exactly as they appear in the source and do not pre-normalise them. Anything that needs context instead of rules — 'Acme & Co' vs 'Acme Pvt Ltd', a name under two codes — comes back in identity_cleaning.review_candidates, unmerged, for you to judge from the surrounding rows and re-send via identity_overrides. Pass customer_name alongside a coded customer_id to have accounts reported by name.
customer_tiering_get_engineFor books LARGER than 500 transaction rows. Returns a complete, runnable Python script that scores the book into A/B/C/D tiers with survival modelling (BG/NBD), spend modelling (Gamma-Gamma), tier migration, a money layer and plain-language decision cards. Run it in your code sandbox against the user's transaction file. The rows never pass through you as tokens, so a 10,000-row book costs the same to run as a 600-row one. Needs numpy. Prints ranked decisions and headline figures; writes the full per-customer ledger to customer_tiering_result.json beside the input file. No customer data reaches this server on this path. SAVE AND RUN THE RETURNED SCRIPT VERBATIM — every block of it is required for the computation. Do not retype it from memory, shorten it, reformat it, split it up, or reimplement the maths with pandas/sklearn; only the PATH / AS_OF / CURRENCY / OUT / OVERRIDES / CONTACTS lines at the bottom may be edited. The script cleans customer identities itself before scoring — merging capitalisation and spelling variants by rule, printing what it merged, and listing the similar-but-unproven groups for you to rule on via OVERRIDES — so do not pre-clean the file or edit those rules. Optionally takes contacts_path, a log of rep calls or visits (customer_id + date only). It is not required and the book scores fine without it, but it is valuable: with it the money layer MEASURES what a contact is worth per tier from touched-vs-untouched tier transitions instead of assuming a flat rate, so ask for it whenever the user mentions a CRM, a call log or a visit register.
Customer Intelligence & Segmentation: подключить к Claude, ChatGPT, Cursor · Connectors.fun