The Account Timeline
The Timeline subtab on the account detail page is the account's whole story in one staff-only feed: when the customer started, every plan change and its outcome, every invoice and payment, every cancellation flow they entered (and whether you saved them), and every note a teammate left — merged into a single stream, newest first. Instead of reconstructing "what happened with this customer" from four different tabs, a rep on a call scrolls one feed and knows.
The timeline is the curated lifecycle view. The Audit Trail subtab remains the exhaustive record — every read, download, and low-level action. The timeline deliberately keeps only the events that tell the customer's story, and just as deliberately includes failures: a failed payment, a failed plan change, or a failed cancellation shows up with a red Failed badge, because a history that hides failures misreports the customer.
Open it from any account — see Finding Accounts and Working with an Account. Everything on it is staff-only (the feed carries a "Staff only" badge); nothing here is ever shown to the customer.
One feed, five families
Every event belongs to one of five families, each with its own color and icon:
Lifecycle milestones
Subscription started, subscription suspended, cancellation committed / revoked, billing contact updates
Plan & products
Plan changes, quantity and frequency changes, add-ons added/removed, orders — including the failed variants
Billing & payments
Invoice generated, payment received, payment failed (with the gateway's response), payment methods added/removed/set default, credit memos, invoice emails
Journeys & retention
Cancellation flows started and completed — a completed flow whose outcome was a save (discount accepted, pause, expert booked) reads "Cancellation saved" with an "Offer accepted" badge; one that ended in a cancel reads "Cancellation completed" with the reason the customer gave
Staff notes
Notes your team writes in the composer (below)
Each event shows who did it — a named staff member, Customer, or System — plus the timestamp, a reference number (subscription, invoice, or payment number) where one exists, and the amount when money moved. Changes with a before and after (quantity, frequency, plan) render a from → to delta pill so the change is legible at a glance.
Filtering, search, and history depth
Family chips across the top filter to one family; each chip carries a live count, and the counts stay stable while a filter is active so you always see the full picture. The Event types legend in the right rail does the same thing.
Search matches event titles, actors, reference numbers, and event details.
Date ranges — All time, last 30 days, last 90 days, or this year.
The feed is grouped by month, newest first, and loads 50 events at a time — Show earlier events pages further back.
The lifecycle stage and key milestones
The right rail derives a stepper and a milestone card from the same data the feed already loaded — no extra billing-system calls:
Lifecycle stage — one of Trial, Active, Active — recovering, Churn risk, Cancelled, or Suspended, rendered as a stepper (trial end, conversion date, current state, next renewal). The states are deliberately honest:
Recovering means a cancellation flow ended in a save within the last 90 days.
Churn risk means the account entered a cancel flow that reached a terminal record without a save — genuine risk, not a completed loss.
Cancelled is terminal. It outranks everything (a cancelled trial reads Cancelled, not Trial), and the stepper stops projecting a next renewal — a renewal date on a churned account would tell you to expect money that isn't coming. A cancellation done directly in the billing system — which leaves no journey record at all — is still recognized, from the subscriptions themselves.
Suspended is not terminal: billing is paused but the relationship can resume. The step reads "since {date}" when the suspension date is known.
Key milestones — first activity, first subscription (by its human-facing number), last plan change, and lifetime billed (the sum of swept invoices). When a value isn't known it shows an em dash, never a fake zero or an invented date.
Billing events come from an opt-in nightly sweep
Invoice and payment events originate in your billing system, so the timeline reads them from a local cache that a nightly sweep keeps fresh — which means opening a timeline costs zero billing-system API calls, no matter how often reps look at it.
The sweep is off by default and enabled per workspace on Settings → Billing Integration Cache, on the Account timeline billing-events sweep card. You pick the hour it runs; a per-run call budget keeps a large account base from hammering the billing system (a very large tenant simply spreads across days).
Run now on the same card triggers an immediate sweep — it runs asynchronously in the background, so you don't sit on a spinner; the card's last-run time updates when it finishes.
Every sweep call is attributed to your workspace in API Call Stats, and a fetch failure for one account is logged and surfaced — never swallowed — before the sweep moves on.
The timeline is honest about freshness. If billing events aren't being synced, a hint tells you where to enable the sweep — but that hint appears only when the server has affirmatively said the sweep is off. While the page is loading, or when the status read itself failed, the timeline stays silent rather than guessing: a failed read is not the same fact as "disabled", and telling a rep to enable a sweep that is already running would point them away from the real problem.
Staff notes
The composer at the top of the feed writes notes straight into the timeline. Notes are never shown to the customer.
Categories — General, 📞 Call, ✉️ Email, 🗓 Meeting, ⚠️ Escalation. The category renders as a chip on the note so a scan of the feed distinguishes "we talked" from "this is escalated".
Pin to top — one pinned note per account (the newest pin wins) renders as a persistent strip above the feed: the right place for "customer is migrating in May — don't upsell". Anyone with notes access can pin or unpin; pinning is curation, not authorship.
Visibility — All staff or CSR team only. Team-only notes are hidden from other staff roles, with two deliberate exceptions: the note's author always sees their own note, and system administrators see everything.
Edit and delete are author-only — only the person who wrote a note can change or remove it, with no time limit either way. Edited notes carry an "edited" timestamp.
Every note action (create, edit, delete, pin) is also recorded in the audit log, so the exhaustive record stays exhaustive.
Logging notes to your CRM
When your organization has a CRM integration connected (Salesforce today), the composer's Add note button grows a split-button option: Add note & log in Salesforce. Your choice is remembered per account, so a rep who always mirrors doesn't re-pick every time.
The option is offered only when it can actually work — the server checks that a CRM integration is active and that this account carries a valid CRM record id. A placeholder id (seeded and test accounts sometimes carry marker values in that field) is detected and named in the explanation, rather than offering a sync that could never succeed.
What gets logged:
Every category logs a completed Activity Task against the account's CRM record — Calls as Call tasks, Emails as Email tasks, Meetings as Meeting tasks. It lands in the record's activity history as something that already happened, not as an open to-do in someone's queue.
Escalation logs a High-priority Task — deliberately never a Case. A Case is a workflow object that assigns owners, sends notifications, and counts against SLAs; a staff note must not fire any of that. High priority is what makes it stand out.
And when the sync fails, you see it: the note itself is always saved first (a CRM outage never loses your note), and the failure renders on the timeline entry in full — the upstream error message, with a Retry button — never quietly dropped. A note that was saved without mirroring can be sent later from its ⋮ menu (Log in Salesforce). Retry is only offered while the target is still valid; if the account isn't actually linked, the timeline says that instead of offering a button that can only fail again.
Admins see the same timeline
The identical Timeline component renders on the admin organization view, against the same account. A CSR and an admin looking at the same customer see the same history, the same notes, and the same composer — the two surfaces cannot drift.
Related
Last updated
Was this helpful?