Stay close to your clients — Client Pulse

Winning the deal is half the job; Client Pulse is the other half. It closes the loop after an account becomes a customer, with three pieces that work together:

1. Usage signals — your own product’s backend sends LeadHunter a tiny ping when a client opens the app, uses a feature, starts a trial, or converts. LeadHunter shows you, per client, when they were last active and which features they actually use.
2. An “In trial” lifecycle stage — sits between In negotiation and Customer, driven automatically by those pings or set by hand.
3. A contact cadence — per company you decide “every client hears from us at least every N weeks” (6 by default). Clients that fall behind surface everywhere you look, until someone reaches out.

The combination is the point: heavy product usage with no recent contact is an upsell conversation waiting to happen; silence on both fronts is churn risk you can still act on.

Send usage pings from your product

Any backend that can make an HTTPS POST can feed Client Pulse. Get your ingest key from Settings → Client Pulse (per company) — like webhook secrets, it’s shown once at creation and can be rotated.

POST https://leadhunter.api.humans2agents.com/api/pulse/ingest/
X-LeadHunter-Ingest-Key: <your key>
Content-Type: application/json

{
  "events": [
    {
      "imported_id": "crm-123",
      "kind": "feature_used",
      "feature": "invoice_upload",
      "occurred_at": "2026-07-11T09:30:00Z"
    },
    {
      "imported_id": "crm-124",
      "kind": "app_opened"
    }
  ]
}

• Batch up to 100 events per request. Send from a background job or queue, never from your product’s request path — a lost ping is noise, a slow request is a real cost.
• Match clients by imported_id — the same correlation key used by webhooks and imports, so an account that came from your CRM is addressable by your record id. You can pass the LeadHunter account id instead if you have it.
• Events that don’t match any account don’t fail the batch — the response lists them under unmatched so you can spot clients that haven’t been imported yet. Never retry an unmatched event in a loop; import the account, then let the next ping land.
• occurred_at is optional (defaults to arrival time), metadata is an optional small JSON object for anything extra you want on the event.

Event kinds

Kind	What it means	What LeadHunter does
app_opened	The client logged in / opened your product	Updates last-seen
feature_used	The client used a specific feature (feature required)	Updates last-seen + per-feature usage counters
trial_started	The client started a trial	Moves the account to In trial
became_customer	The client converted	Moves the account to Customer (and captures account value)
churned	The client cancelled	Moves the account to Lost
custom	Anything else (feature names it)	Counted like a feature, triggers nothing

If several of your products feed the same company, namespace the feature slug by product — accountant.invoice_upload, nutrilens.scan — so the per-client feature list stays readable.

The “In trial” stage

trial_started moves an account to In trial from any earlier pipeline stage — including Lost: a returning trial reopens the relationship, and the status history records the reopening so nothing is silently un-lost. It never demotes an existing customer, and Do not contact is never touched.

Trials are protected from cold outreach the same way customers are: campaign goals that block customers also block trials, with an explicit include trials override when a campaign genuinely targets them. Status changes made by pings appear in the account’s history with their own source, so you can always tell automation from a human edit.

Configure the contact cadence

In Settings → Client Pulse (per company):

• Contact every N days — default 42 (6 weeks).
• Tracked stages — by default Customer and In trial; add In negotiation if you want the nudge pre-close too.
• Weekly digest — on by default; pick the weekday. Every company member gets it.

Per client, on the account page, you can override the cadence (“this one is high-touch — every 2 weeks”) or snooze the reminders until a date (“they asked for space until September”).

What counts as contact: logging an outbound message on any of the account’s conversations (see logging conversations) or recording a contact event on the account. Either resets the clock. Inbound replies don’t — them writing you is not you keeping in touch.

Where overdue clients surface

• The Clients page (Dashboard → Clients) — every tracked client with last contact, last seen in your product, top features, and a days-overdue badge; sorted most-overdue first. Log a touch or snooze directly from the row.
• The weekly digest email — the overdue list, each row pairing last contact with last seen, so churn risks and upsell openings read differently at a glance.
• The dashboard home — an “Overdue clients” card linking to the filtered list.
• A webhook — subscribe to the client.contact_due event (see webhooks) to route nudges into Slack or your own tools. It fires once per overdue episode, not once per day — it re-arms only after someone actually makes contact.

Reading a client’s pulse

Each account’s detail page carries a Pulse card: first and last seen, activity over the last 90 days, and which features the client uses most. Use it before every check-in call — “I saw you’ve been using the CSV export a lot” is a much better opener than “just checking in”.