Account inactivity: 5 checks to choose your next task

• Interaction history checks: Locate specific activities within your CRM records.
• Activity window checks: Separate daily, weekly, and monthly definitions.
• Cohort freshness checks: Verify if data updates automatically or remains a snapshot.
• Retention definition checks: Read the denominator and selected milestones.
• Support search checks: Allow for indexing delays before treating absence as evidence.

By tracking all your customer interactions—every email, phone call, task, and appointment—you create a complete history that your entire team can reference, according to Microsoft. This recorded history forms the baseline for distinguishing missing activity from stale evidence.

Start by reviewing the complete interaction history to confirm whether the account has logged recent communication. If the history is empty, investigate whether the data source is stale rather than assuming the customer is inactive. Each check isolates a specific type of evidence gap. Resolving these gaps prevents assigning a follow-up task based on incomplete or outdated information.

The first step is to locate the documented interaction history rather than treating product events as the entire customer relationship. In the site map, find your activities under My Work > Activities, according to Microsoft. This location holds the recorded interactions that form the baseline for any inactivity check. Related setup for those records is in Activity types: 6 defaults before the kickoff call. Do not assume that a lack of product events equals a lack of relationship activity; the recorded interaction list is the specific evidence to review first.

Once the interaction history is located, match it against the correct activity window. The documented windows are distinct and must be kept separate to avoid conflating different time periods. Daily Active Users (DAU) is defined as the number of users who performed [event] within the last 24 hours, according to Mixpanel. Weekly Active Users (WAU) is defined as the number of users who performed [event] within the last 7 days, according to Mixpanel. Monthly Active Users (MAU) is defined as the number of users who performed [event] within the last 30 days, according to Mixpanel. These definitions establish the specific time boundaries for each metric. When investigating an account, identify which of these windows applies to the observed silence. A gap in the last 24 hours is a different evidence point than a gap in the last 30 days.

The aggregation method used to calculate these metrics also affects how the data is read. The default aggregation is Average, which you can click on to select a different option such as distribution, median, 25/75/90th percentiles, minimum, and maximum, according to Mixpanel. Before interpreting a low activity count, verify which aggregation is currently selected. An average value may mask significant variation within the cohort. If the goal is to identify specific accounts with zero activity, a distribution or minimum view may be more relevant than the default average. Check the selected aggregation to ensure the metric aligns with the specific inactivity question being investigated.

Before you label an account as inactive, verify whether the data source updates automatically or remains a static record. In PostHog documentation, dynamic cohorts are updated once every 24 hours PostHog. If you rely on a dated snapshot, the cohort captures the users matched in the trailing window, which defaults to 30 days, and it won't live-update as new observations come in PostHog.

To distinguish between a customer who has stopped engaging and one who has simply resumed activity after a pause, look at the specific event definitions. PostHog defines "Stopped doing an event" as a user who stopped doing a shared insight event in the "last 5 days" but had done it in the "5 days prior" PostHog. Conversely, "Started doing event again" identifies a user who started doing a shared insight event in the "last 5 days" but had not done it in the "5 days prior" PostHog. These five-day windows provide a concrete way to check for recent changes in behavior. A user in the "resumed" category may not need immediate follow-up, whereas a user in the "stopped" category might warrant investigation.

When you review retention metrics, ensure you are comparing like with like. Always note the date of the cohort or the update frequency when you record your findings.

Before interpreting a change in account activity, confirm which retention milestone you are actually reviewing. A quiet account may simply be past the window you selected, or the cohort you are comparing may use a different denominator than the one you assume.

Amplitude's documentation on interpreting retention analysis frames the question in terms of specific milestones. You may want to know how a new release has affected your product's Day 1 retention rates, or if a new training program has had an impact on your Day 14 retention rates, according to Amplitude. This distinction matters because a Day 1 dip and a Day 14 dip point to different stages of the customer journey. If you are investigating inactivity for an account that is three weeks old, a Day 1 retention metric will not reflect its current behavior.

The calculation behind that percentage is specific. Amplitude calculates this percentage by dividing 1) the number of users from each new user cohort who triggered the return event on each retention day, by 2) the number of users who were new on the selected day, according to Amplitude. When you look at a retention chart for a customer account, the denominator is the size of the new-user cohort for that specific calendar date. If the cohort was small, a single user leaving can create a large percentage drop that looks like inactivity but is actually a statistical artifact of a small base. Check the cohort size before assuming the account is disengaged.

The milestones themselves are fixed points in time. Each of the four lines follows one retention milestone, Day 1, Day 7, Day 14, and Day 30, across the new-user cohorts by calendar date, according to Amplitude. When you choose a follow-up task, select the milestone that matches the account's age. For an account that is eight days old, the Day 7 line is the most relevant comparison. For an account that is two weeks old, the Day 14 line is the correct reference. Using the wrong milestone leads to misdiagnosis. A companion walkthrough is Retention analysis chart: 3 steps across tools.

Treat an empty support search result as provisional evidence until you have confirmed the indexing status of the records. You can define filters to narrow your search results according to resource type, dates, and object properties, such as ticket requester or tag, according to Zendesk. Applying these specific constraints helps isolate the relevant subset of interactions for the account you are investigating. Before you promise a reply time, see Check 4 SLA reply clocks before you promise a time. Keep the resource type aligned with the specific support channel the customer used, and set the date range to cover the period of suspected inactivity. Object properties like ticket requester or tag allow you to filter for specific individuals or categories within the account, ensuring the search targets the correct data points.

Newly created resources may not appear immediately in search results. It can take up to a few minutes for new tickets, users, and other resources to be indexed for search, according to Zendesk. Do not interpret the absence of a recent ticket as proof that the customer has not created one.

If new resources don't appear in your search results, wait a few minutes and try again, according to Zendesk. This retry step is necessary to distinguish between a true lack of activity and a temporary indexing lag. If the ticket still does not appear after the wait, you can then consider the absence as a valid data point for your inactivity assessment. Always verify that your filters remain applied during the retry to ensure you are searching the same scope.

The following table summarizes the documented definitions and rules for each of the five checks, with each row sourced exclusively from the corresponding publisher's documentation.

Use this table to verify which specific definition applies to your current investigation before assigning a follow-up task.

Take one account that looks quiet. Five checks are still open. The last product event falls inside a 30-day window and outside a 7-day window, so those two windows are different evidence. On an illustrative new-user cohort of 100 people, 90 trigger the return event on day 7. That reading is 90 out of 100, and it is only a worked example, not a measured result. You still mark whether the cohort is a dated snapshot with a 30-day trailing window, and you still wait before treating an empty support search as final. After those checks, you choose the follow-up task.

Choose one account that appears quiet, inspect its recorded interactions, and identify which activity window or data-freshness check you need to resolve before assigning a follow-up task. Record the specific date and time of the last logged interaction for the account. Note which of the five checks remains unresolved: interaction history, activity window, cohort freshness, retention definition, or support search. If the cohort is a dated snapshot, mark it as stale evidence rather than current activity. If the support search returned no results, note the indexing delay and schedule a re-check.

How do I investigate customer account inactivity?

Review recorded interactions, then separate the activity window, cohort freshness, retention definition, and support search before you choose a follow-up task.

What time windows do daily, weekly and monthly active users measure?

Daily Active Users measure the last 24 hours, Weekly Active Users measure the last 7 days, and Monthly Active Users measure the last 30 days.

Does my PostHog cohort update automatically or remain a dated snapshot?

Dynamic cohorts are updated once every 24 hours, but a dated snapshot captures users in the trailing window and won't live-update as new observations come in.

How does Amplitude calculate retention for a new user cohort?

Amplitude calculates the percentage by dividing the number of users who triggered the return event on each retention day by the number of users who were new on the selected day.

When should I repeat a Zendesk search for a newly created ticket?

Wait a few minutes and try again if new resources don't appear in your search results, as it can take up to a few minutes for new tickets to be indexed.

This post is general operational information, not legal advice about notice periods or renewal clauses. It does not promise that any method keeps a customer. A review model checked the facts once, and that check can miss errors, so open the sources before you act.