> 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/working-with-an-account.md). # Working with an Account The account detail page is the CSR's single-account workspace: everything about one customer — identity, key financial metrics, subscriptions, invoices, payments, and any journey work in flight — on one screen, so a rep on a call never has to tab between systems. Open it by selecting an account from the [accounts list or global search](/product/customer-success-portal/finding-accounts.md). ## The account header The header shows the account name, its account number, the billing system it lives in, and its status, with a breadcrumb back to **Accounts**. Below it, a five-tile metric strip gives the financial picture at a glance: **Net MRR**, **Next Billing**, **Balance**, **Customer Since**, and **DSO**. Hover a tile's info icon for a plain-English explanation of the figure and where it comes from — DSO's tooltip, for example, reads *"The average days customers take to pay this account's invoices, based on matched invoice and payment pairs"*, and when no matching pairs exist it says the figure can't be calculated (the tile shows **N/A**) rather than showing a number it can't back up. If any of the account's subscriptions is scheduled for cancellation, a banner at the top of the page says so — including the effective date — so no one runs a change on an account that's already on its way out without knowing it. The subscription card itself carries the same fact in miniature: a **"Scheduled for {date}"** caption directly under the status badge. And when the retention journey's revoke setting is enabled, an eligible scheduled cancellation shows a revoke strip right on the card, so a rep can undo the cancellation before the date arrives — the counterpart of the cancellation flows described in [Customer Subscription Management](/product/customer-self-service/subscription-management/customer-subscription-management.md). ## The Customer card The **Customer** card in the sidebar collects the account's identifying details: primary email, billing system, external account number, the **CRM id**, and how long they've been a customer (plus a fraud/risk score when one is available). When your organization has a CRM integration connected (for example Salesforce), the CRM id renders as a **link that deep-links straight to the account's record in your own CRM instance** — one click from the PeakCommerce workspace to the CRM record, opened in a new tab. The link targets *your* CRM domain, not a generic login page, so it lands directly on the record. If the account carries no CRM id, the row shows an em dash — the field is always present so the card reads consistently across accounts. ## In-flight changes When a [journey](/product/journeys-and-pages/journey-basics/journeys-overview.md) — a plan change, a cancellation/save flow — is started on this account and not finished, it surfaces on the relevant subscription card. Without that, a half-completed wizard would be invisible: the session stays alive server-side, but nobody would know to go back to it. How sessions render depends on whose they are and how many there are: * **Your own resumable sessions stay pinned as full banners**, tagged **YOURS**, showing the journey, the step you're on, and when you last touched it — with a prominent **Resume** button. Your sessions never get compressed away. * **One or two other sessions** (started by other CSRs, or by the customer) render as dense rows beneath. * **Three or more other sessions collapse into a single collapsible strip** per subscription: a one-line summary ("2 plan changes · 1 cancellation in progress"), a count badge, a facepile of who started them, the oldest start date, and a call-out when any have gone stale. Expand the strip to see every row. Each row shows the actor, **who is driving it** (a CSR or the customer), when it started, its last activity, and a **type chip** — **Plan change**, **Cancellation**, **Add-on change**, or **Other change**. When an expanded strip contains mixed types, **type filter chips** appear so you can look at, say, just the cancellations. ### Resume, Dismiss, Abandon — and View A row's **actions menu** (⋮) offers up to three actions, plus a read-only view: * **Resume** — appears only when the session is resumable *by you*: it's your own session, for a journey your profile lets you run. Resuming reopens the flow at the exact step you left off, with everything already collected still in place. * **Dismiss** — hides the entry **just for you**. Dismissals follow your user account (they persist across browsers and devices), and other CSRs still see it. If the session later sees new activity, it **resurfaces** for you — a dismissed session that wakes up is news you want. * **Abandon** — **ends the session server-side, for everyone.** The session's status becomes abandoned, it disappears from every CSR's in-progress list, and it **cannot be resumed afterwards**. Use it when a session was started in error or is permanently stale. Abandonment is recorded in the session's history, so analytics and the audit trail reflect who ended it and why. * **View** — opens the session **read-only** (observe mode). Any same-tenant CSR or admin can watch exactly where a flow stands — which step, what's been chosen — without being able to advance it or touch the owner's progress. Useful when a customer calls mid-flow and asks "where was I?", and safe by construction: peeking cannot corrupt a live session. ### Stale sessions and bulk cleanup A session with no activity for **more than 14 days** is marked **stale**. The expanded strip's **Bulk** menu offers **Dismiss all** (cosmetic, just for you) and **Abandon stale (n)…** — which always confirms first, listing exactly which sessions it will end, because abandoning is terminal and global. Customer-driven sessions are an opt-in view per CSR (**Show customer activity**, visible only to roles with the observe capability), rendered in blue with a View-only button, so the page stays uncluttered for reps who don't co-pilot live customer flows. ### In-flight gotchas * **Dismiss and Abandon are very different.** Dismiss is cosmetic and personal; Abandon is terminal and global. If you only want the entry out of *your* way, Dismiss. * **Abandon can't be undone.** An abandoned session is gone for good — the customer or CSR would start the journey fresh. When in doubt, Dismiss instead. * **No Resume on a row?** Either the session belongs to someone else, or your profile isn't assigned to that journey. Use **View** to see where it stands. ## Payment methods The **Payment Methods** area lists the account's stored methods — card type, last four digits, expiry, status, and a **Default** badge — read straight from the billing system. What you can do with them is permission-gated: viewing requires the payment-methods read permission, and the write actions require update. * Each row's actions menu offers **Make default** and **Remove…** (with a confirmation). * **Add payment method** opens a modal that runs the **billing system's own hosted payment page** — the card details are entered on the billing provider's secure form and never pass through PeakCommerce. * Admins choose *which* hosted page the Add flow uses via the block's **integration-aware hosted-page picker** in the page editor — the picker lists the pages that belong to the account's billing integration. Leaving it blank uses that integration's default hosted page. ## Sub-accounts The **Subaccounts** subtab lists the account's children exactly as the billing system's own account hierarchy defines them — accounts that bill under this one. It's a read-only list of name, account number, status, and balance; each row's actions menu (⋮) offers **View Account**, which opens the child's own account detail page. Two honest limits: * The hierarchy read is available on **Zuora-backed accounts**. On other billing systems the tab plainly says sub-accounts aren't available for that billing system, rather than guessing at a hierarchy it can't see. A failed load likewise shows as an error with a Retry — never as "no subaccounts". * Creating a sub-account happens through a journey, not an inline form: a subscription card's **Manage → Create Subaccount** entry appears when an admin has authored a journey with the **create\_subaccount** purpose. The journey launches with the current account injected as the parent, and its confirmation step can show the newly created account's number. ## Timeline The **Timeline** subtab merges the account's entire history — lifecycle milestones, plan changes, billing events, cancellation/retention flows, and staff notes — into one staff-only feed, with a lifecycle stepper and a notes composer that can mirror into your CRM. It has its own page: see [The Account Timeline](/product/customer-success-portal/account-timeline.md). ## Acting on the account From the subscription cards you launch the CSR journeys themselves — change plan, cancel/save, and whatever else your organization has built for the CSR surface. The changes those flows commit are driven by the journey's [commerce actions](/product/journeys-and-pages/journey-steps/commerce-actions.md), and everything a rep does is attributed to the rep in the [audit log](/product/reporting-and-analytics/audit-trail-and-logs/audit-logs-overview.md). ## Related * [Customer Success Portal Overview](/product/customer-success-portal/customer-success-portal-overview.md) * [Finding Accounts](/product/customer-success-portal/finding-accounts.md) * [The Account Timeline](/product/customer-success-portal/account-timeline.md) * [Journeys Overview](/product/journeys-and-pages/journey-basics/journeys-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/working-with-an-account.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.