> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/product/customer-success-portal/account-timeline.md). # 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](/product/customer-success-portal/finding-accounts.md) and [Working with an Account](/product/customer-success-portal/working-with-an-account.md). 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: | Family | What lands here | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **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 **your own team only**: the team tier matches the portal you're writing from (**CSR team**, **Sales team**, or **Partner team**). Team-only notes stay within that team's portal — a CSR-team note is not visible to Sales staff, and a Sales-team note is not visible to CSRs — 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](/product/reporting-and-analytics/audit-trail-and-logs/audit-logs-overview.md), 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. ## Every staff workspace sees the same timeline The identical Timeline component renders in the CSR, Sales, and Partner account workspaces as well as on the admin organization view, against the same account. A rep and an admin looking at the same customer see the same history, the same notes (subject to the team-visibility rules above), and the same composer — the surfaces cannot drift. ## Related * [Working with an Account](/product/customer-success-portal/working-with-an-account.md) * [Finding Accounts](/product/customer-success-portal/finding-accounts.md) * [Customer Success Portal Overview](/product/customer-success-portal/customer-success-portal-overview.md) * [Audit Logs Overview](/product/reporting-and-analytics/audit-trail-and-logs/audit-logs-overview.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.peakcommerce.com/product/customer-success-portal/account-timeline.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.