Nucleus logonucleus
‹ All use cases
Bablic · customer migration

A platform migration, worked one account at a time.

Moving a legacy customer base onto a new product doesn't happen in a single batch. Each account needs someone to pick it, research it, contact it and follow up. Here the sales team does that from Claude, through Nucleus tools that know which rep is asking, show only what that rep may see, and record every claim and note under that rep's name.

Governed tools45 Identityper rep Writesapproved Installnone
A rep, in Claude
Pull today's migration targets.
Claude, through Nucleus
get_failed_payment_projectsget_expiringget_churned_customersget_contact_outreach
Ten accounts nobody has claimed yet:
LAPSEDatelier-example.frpayment failed 9 days ago RENEWINGexample-yoga.comannual, renews in 26 days CHURNEDshop.example.deleft 8 months ago, 6 yrs a customer … 7 more, each with a reason
Claim all 10 and add notesEdit the list
01

The legacy customer base, as 45 tools

The legacy platform's sites, accounts, plans, payments and translations are imported into a staging database built for the migration. That database is exposed through Nucleus as one MCP server of 45 tools. Reps never touch the legacy system, and the tools never touch it either.

What the tools answer

Questions a rep would otherwise take to an engineer.

  • Which paying customers are coming up for renewal, have lapsed, or have left
  • How hard each site is to move, scored low, medium or high from its deployment and languages
  • Which plan and traffic band each customer belongs on in the new product
  • How migration is progressing for each source platform and site builder

What the tools let a rep do

Writes, each recorded as the rep who made it.

  • claim_contact takes ownership of a customer and all their sites
  • add_outreach_note logs a call, email or meeting
  • update_outreach_status moves a contact from in contact to trial to converted
  • set_migration_flag marks a site ready for the new platform
02

Every morning: ten accounts, picked by rule

A shared Claude skill turns "who should I call today?" into the same three queries for every rep, in priority order. It re-checks that nobody else has claimed each account, and nothing is claimed until the rep approves the batch.

Tier 1 · already slipping

Payments that lapsed

Accounts whose payment already failed or whose plan already expired. They're the closest to leaving, so they're contacted first.

get_failed_payment_projects · get_expiring
Tier 2 · a natural moment

Annual renewals this quarter

A renewal is the moment a customer is already thinking about the product, which makes it the easiest time to move them.

get_expiring · period: quarter
Tier 3 · worth winning back

Customers who left

Customers lost six to twelve months ago, ranked by what they were worth over their whole time as customers.

get_churned_customers · by lifetime value
The skill writes down the judgment once, and it runs the same way for every rep. Each rep gets a daily list built by the same rules, with a reason beside every account, instead of whatever they remember to look up. The rules live in the skill, the data comes from Nucleus, and the rep makes the decision.
03

A week later: the follow-up, researched first

An account that was contacted and then went quiet for seven days gets a follow-up, and a follow-up only lands if it shows the rep knows the account. A second skill does the research with read-only tools before drafting anything.

01

Who is this customer?

get_client_profile · get_contact · search_projects

Their sites, contacts, plan and how long they've been a customer.

read
02

What have they paid, and what happened last time?

get_payment_history · get_project_revenue · get_contact_outreach

Payment history and every earlier note, so the follow-up continues the last conversation instead of starting a new one.

read
03

How hard is their move?

get_migration_complexity

How the site detects language, its URL rules, glossary and enabled languages, scored low, medium or high. A customer with a glossary and ten languages needs a different email from one with a single language.

read
04

Draft the follow-up

Claude

Every claim in the draft has to come from a tool result. If a fact isn't in the data, it doesn't go in the email.

draft
05

Log it, with the rep's yes

add_outreach_note · update_outreach_status

The note and any status change are written only after the rep approves, and they're recorded as that rep.

approved write
04

Why this is safe with a whole sales team

Ten reps working one customer base from an AI assistant is a recipe for two of them emailing the same customer, or for an assistant writing notes nobody can attribute. Nucleus rules both out structurally.

Every call knows who's asking

The gateway passes the person's identity on every request.

  • "My pipeline" is filtered to the person asking, not to whoever set up the tool
  • Claiming an account someone else holds returns "already claimed"
  • Only the rep who holds an account can change its status, value or notes
  • Every row records who created it and who last changed it

Automation is labeled as automation

A scheduled job can help, but it can't pose as a rep.

  • A workflow can add a note to an account a rep owns, on that rep's behalf
  • The note's author is still recorded as the workflow, never as the rep
  • Automated claims are marked queued rather than in contact
  • The same rate limits and audit apply to the workflow as to a person
None of this depends on the assistant behaving well. A rep could ask Claude to "just update that account", and the tool would still refuse if the account belongs to someone else. Ownership is enforced in the tool, using the identity Nucleus attached, not in a prompt.
The difference

A migration program the whole team can work, with every action on the record.