Getting started with Exeechain: the setup path for 10 kinds of SaaS teams

Every CS platform says “live in minutes.” What that actually means depends entirely on what your stack looks like: a bootstrapper with only Stripe has a different first hour than a sales-led team living in Salesforce, and both differ from a founder whose CRM is a spreadsheet. So instead of one generic checklist, this guide walks the exact setup path for ten real situations, with the actual clicks, the actual code, and what you should see at each checkpoint. Find yours and follow it.

Before you start: the two feeds and the honesty rules

Strip away every integration logo and Exeechain needs exactly two inputs: who your customers are (with revenue attached) and what they are doing (usage, payments, support, sentiment). Everything on the integrations page is just a different way of supplying those two feeds, and every native connector has a generic fallback. That is why none of the ten situations below is blocked.

Four honesty rules shape everything you will see, so know them up front:

1. Day-one scores are labeled “early read.” Every score carries a confidence value driven by how much real data backs it. Thin data means low confidence, and the UI says so next to the number.
2. Not enough data means no score at all. An account below the data-sufficiency floor stays unscored rather than getting an invented number. Missing signals are simply removed from the formula; absence never counts as risk.
3. Low confidence never pages you. Scores below the alert threshold cannot trigger alerts or autonomous agent actions. A half-connected workspace cannot spam you.
4. Nothing emails a customer without approval. Drafted outreach waits in your queue. Autonomous sending is earned per action type over time, respects quiet hours in your timezone, and never applies to your largest accounts.

One practical note before the situations: your API key lives at Settings → Integrations. It is shown in full exactly once (keys are stored hashed, like passwords), so copy it when you see it. If you lose it, click Rotate key: you get a fresh key instantly and the old one stops working.

Situation 1: Stripe is your whole stack

Who this is: a bootstrapped founder. Billing is Stripe; there is no CRM, no analytics tool, no help desk. You do CS from your inbox.

Setup

1. In Stripe: Developers → API keys → Create restricted key. Grant read access to Customers, Subscriptions, and Invoices. Nothing else, and no write scopes: Exeechain never writes to Stripe.
2. In Exeechain: Integrations → Stripe, paste the rk_live_... key. The key is stored encrypted.
3. Wait about a minute. The import pulls your customer list, MRR, plan, payment history, and failed charges, then the Diagnosis runs automatically.

What you will see

A “Here is what we found” screen: recoverable revenue with real account names and real dollar amounts, split into failed payments you can chase today and renewals approaching without confirmation. Most Stripe-only teams find four figures of recoverable revenue in the first ten minutes, and that number is checked against your billing data, not estimated.

Watch out for

• Billing-only scoring is deliberately conservative: payment health, renewal proximity, and account age work, but usage-driven signals abstain until you add tracking. Add the snippet (Situation 4 shows the code) in week one and watch the scores sharpen the same day.

Situation 2: You use none of the integrated platforms

Who this is: your billing is an invoice ledger or a regional processor, your CRM is institutional memory, and your analytics tool does not exist. This path works end to end; we test it regularly with exactly this stack.

Setup

1. Customers via CSV. Export whatever you have to CSV and upload it at Setup → Upload a CSV. The only required column is an email per customer. Useful extras, auto-detected even under messy headers: company name, monthly revenue, plan, status (active or churned), a stable customer ID from your own system, and signup date. A header row like Company Name, Contact Email, Monthly Revenue, Plan, Status, Customer ID, Signed Up maps with zero manual work; you confirm the mapping on a preview screen before anything imports.
2. Usage via the snippet. One script tag in your product (full code in Situation 4).
3. Support via BCC. Your workspace has a private logging address, shown at Settings → Auto-log, of the form log+yourworkspace@exeechain.com. BCC it on customer email (most teams add it to their support tool's outbound signature or their CRM's BCC field). Exeechain reads tone, cancellation hints, budget concerns, and competitor mentions from the thread itself.
4. NPS built in. No survey tool needed: Exeechain sends its own NPS surveys to the customer emails you imported, and responses flow straight into scoring.

What you will see

After the CSV: your accounts with ARR computed, renewal dates inferred from signup anniversaries (marked as unconfirmed until a real contract date exists), and the Diagnosis over whatever billing facts you provided. After the snippet: usage signals appear within minutes of the first real login. Churned customers from your CSV are excluded from scoring automatically.

Watch out for

• CSV is a snapshot, not a feed. Re-upload when things change, or graduate to the Customers API (Situation 7) for a live upsert. Re-uploading the same file is safe: rows match on your customer ID or email and update in place instead of duplicating.

Situation 3: Migrating from Gainsight or ChurnZero

Who this is: you have a heavyweight CS platform, an admin who maintains it, and a renewal coming up that you would rather not sign.

Setup

1. Export your account list from the old tool as CSV (both Gainsight and ChurnZero can export accounts with ARR/MRR, stage, and lifecycle fields). Upload at Setup → Upload a CSV; the mapper handles their column names.
2. Connect Stripe or your billing source. This is what makes recovered revenue verifiable: Exeechain only books a save when billing confirms the renewal actually happened.
3. Recreate your top plays as workflows. Do not port all forty playbooks; start with the three that matter (renewal runway, payment rescue, onboarding) from the starter library, or describe one to the Copilot in plain English and review its draft.

What you will see

Day-one parity on the things you actually used: scored accounts, a renewal pipeline, drafted outreach waiting for approval. Your first AI-written QBR takes about thirty seconds against the six to ten hours you are used to.

Watch out for

• Run both tools in parallel for a month if you like; Exeechain is month-to-month, so the switch carries no contract risk. Keep the old tool read-only during the overlap so nobody double-sends outreach.

Situation 4: PLG with hundreds or thousands of small accounts

Who this is: self-serve signups, low touch, too many accounts to eyeball. Churn shows up in usage weeks before it shows up in billing.

Setup

Install the snippet with account and seat identity. This is the single highest-leverage config decision in this guide:

<script src="https://exeechain.com/exeechain.js"></script>
<script>
  Exeechain.init('YOUR_API_KEY');
  // The company this session belongs to - YOUR stable id for them
  Exeechain.setAccount(currentUser.companyId);
  // The individual seat - unlocks seat-utilization risk
  Exeechain.trackLogin(currentUser.id);
</script>

Then instrument the two or three features that define activation:

Exeechain.trackFeature('report_created');
Exeechain.track('invoice_sent', { amount: 4200 });

1. Sync accounts in bulk through the Customers API (Situation 7), batched up to 1,000 per request, keyed on your own external_id so the snippet's setAccount() calls match the same customers automatically.
2. Turn on two segment workflows from the starter library: renewal-within-90-days and churn-risk-crosses-70. They continuously enroll every matching account, so coverage does not depend on anyone looking.

What you will see

Seat utilization becomes a first-class risk signal: an account that bought ten seats and has two people logging in gets flagged while their payments are still on time. The per-step workflow funnel shows exactly where accounts drop out of your renewal play (“56 entered, 41 through, 6 booked a call”), so you fix the step instead of guessing.

Watch out for

• Call setAccount() with your company ID, not the user ID. Skipping it makes every seat look like its own customer, which wrecks both your customer count and your scores.
• If the snippet seems silent, open the browser console: tracking before init() logs a warning telling you exactly what is wrong.

Situation 5: Sales-led B2B living in Salesforce or HubSpot

Who this is: annual contracts, named CSMs, QBRs, real renewal dates in the CRM, and champions whose job changes can sink an account.

Setup

1. HubSpot: Settings → Integrations → Private Apps → create an app with CRM object read scopes, paste the pat-na1-...token into Exeechain's HubSpot card. Salesforce: the OAuth connect flow on the Salesforce card; sync is bi-directional and can push churn scores back onto the Account record.
2. Connect billing as well. The CRM brings renewal dates, owners, and champions; billing brings the money truth that saves are verified against.
3. Enable the renewal-runway workflow. It anchors to the actual renewal date on the account, not a guessed delay chain, and enrolls everyone inside 90 days.

What you will see

Champion tracking starts watching your key relationships; champion-departure events are a real-time trigger, so the agent reacts within seconds, not at the next weekly review. The renewals page stops being a spreadsheet you update the night before pipeline review.

Situation 6: Support-heavy product, the inbox knows first

Who this is:your support queue hears “we are evaluating alternatives” three weeks before any dashboard shows a problem.

Setup

1. Zendesk:subdomain, agent email, API token (Admin → Apps & Integrations → Zendesk API). Intercom: access token from Settings → Developers. Either connects in about two minutes.
2. No help desk? BCC customer email to your log+...@exeechain.com address (Settings → Auto-log) and paste important call transcripts (Gong, Fathom, or hand-written notes) into the account timeline. Same analysis, same signals.

What you will see

Conversation intelligence reads every thread for cancel intent, budget concerns, frustration, and competitor mentions. A cancel-intent signal is a real-time trigger: it can start a workflow or a targeted agent run within seconds of the message arriving, with the draft response waiting in your approval queue.

Situation 7: The engineer-founder who wants API-first

Who this is: you have a warehouse, you write code, and you would rather push data than click through connectors.

Setup

Accounts, as a live upsert keyed on your own IDs:

curl -X POST https://exeechain.com/api/v1/customers \
  -H "Content-Type: application/json" \
  -d '{
    "api_key": "YOUR_API_KEY",
    "customers": [
      { "email": "jane@acme.com", "external_id": "crm_123",
        "name": "Acme Inc", "mrr": 1200, "plan": "Growth",
        "status": "active" }
    ]
  }'

Usage events, with timestamps so you can backfill history and an idempotency key so retries never double-count:

curl -X POST https://exeechain.com/api/v1/track \
  -H "Content-Type: application/json" \
  -d '{
    "api_key": "YOUR_API_KEY",
    "customer_id": "crm_123",
    "event": "login",
    "user_id": "jane@acme.com",
    "timestamp": "2026-07-20T09:14:00Z",
    "event_id": "evt_8842"
  }'

Or skip ingestion entirely and push raw signals from your own pipeline for a scored answer:

curl -X POST https://exeechain.com/api/v1/predict \
  -H "Content-Type: application/json" \
  -d '{
    "api_key": "YOUR_API_KEY",
    "customer_id": "crm_123",
    "signals": {
      "days_since_login": 23,
      "login_count_last_30": 1,
      "login_count_prev_30": 9,
      "payment_failed": false,
      "mrr": 1200
    }
  }'

The contract details that matter

• Batches up to 1,000 customers per request; roughly 1,000 events per minute per workspace; event properties up to 16 KB.
• Updates are partial: send only external_id and mrr in a nightly sync and nothing else changes. A revenue update will never rename an account or resurrect a churned one.
• Duplicate deliveries with the same event_id are acknowledged and stored once. Retry freely.
• A special event name, payment_failed, feeds the payment-health signal directly, so non-Stripe billing systems can report failures too.

Situation 8: CS run from a spreadsheet

Who this is: a founder or one CS person, a Google Sheet with fifty to three hundred rows, gut feel for who is unhappy.

Setup

1. File → Download → CSV, then Setup → Upload a CSV. Your human column names are fine; you confirm the auto-mapping on a preview before importing.
2. That is genuinely it for day one. Add the snippet in week two.

What you will see

Billing-informed scoring immediately (payment facts, renewal proximity, account age), clearly labeled early-read. The Data Health page (Settings → Data health) tells you exactly which signal to add next and what it unlocks, in order of impact, so the upgrade path from spreadsheet to full detection is a checklist rather than a project.

Situation 9: You are in churn-crisis mode right now

Who this is: two bad months, board questions, and no time for a six-month platform rollout.

Setup

1. Run the free leak scan before paying anything: connect Stripe read-only and see failed payments and lapsing renewals with names and amounts.
2. On day one, work the at-risk watchlist top-down. Every account shows its dollars, its top reasons in plain English, and a Save Plan button that drafts the rescue: an executive brief, three approved actions, and outreach written from the account's own data.
3. Approve or veto from the queue. Nothing sends without you; the save plans just remove the blank-page problem at the worst possible time.
4. Do not write off the already-churned: the win-back module re-engages lost accounts with an approved offer, and only books the revenue that verifiably comes back.

Watch out for

• Resist bulk-sending everything the first day. The approval queue ranks by revenue impact and confidence; work it in order and let the quiet-hours guard do its job. A rescue campaign that reads like a panic blast performs like one.

Situation 10: Agency or portfolio operator

Who this is: you run CS for several products or clients, and their data must never mix.

Setup

1. One workspace per client: separate customers, separate API keys, separate approval queues, hard tenant isolation at the database layer.
2. Create additional workspaces from the workspace menu (the + next to the workspace name). CS Command includes three workspaces; Total Command is unlimited.
3. Each client connects whatever stack they have; every situation above applies per workspace independently.

The first two weeks, honestly

Minute 15: customers imported, ARR computed, Diagnosis surfaced, first scores labeled early-read, the watchlist ranked. Day 2 or 3: usage signals are flowing if you installed the snippet; drafted rescues are accumulating in the approval queue; nothing has been sent that you did not approve. Week 2: confidence has climbed with real history, the early-read labels are disappearing on data-rich accounts, and the agent has started earning autonomy on the small, safe action types while your whale accounts remain approval-only. Week 4: the first verified saves appear, and the ROI page shows dollars that were confirmed against billing rather than estimated, which is the number you can take to a board meeting.

Ready to find your situation in the product? Start with the free diagnosis or see plans.