--- name: gainsight-customer-communities-community-health-review description: Run a periodic health read of a Gainsight Customer Community across engagement, content and moderation load, using the analytics and admin overview tools, and turn it into a prioritised summary for a community manager. Use when the user asks for a community health check, a weekly or monthly community review, an overview of how the community is doing, or what needs attention in the community this period. --- # Community health review A health review answers one question: **what in the community needs a manager's attention this period, and what is just noise?** It is a scheduled, cross-area read. It is not a search for one thread and not a list of product requests. Each area (engagement, content, moderation, recognition, structure) gets a read, then the reads are compared so that one finding can be confirmed by a second area before it is ranked. ## 1. Confirm the scope and the period first Before calling anything, fix three things with the user and state them back: - **Community.** This connector reaches one community at a time. Confirm which one, and that the active account is the one the user expects. Switching the active account or workspace is a change of state: wait for the user's explicit yes before doing it. - **Period.** Last week, last month, or the quarter. Every trend in the review is relative to the previous period of the same length, so write down both windows. - **Role.** The tools shown depend on the signed-in user's community role. If a whole area is missing from the tool list, say the review covers only what this role can see, rather than implying the area is quiet. ## 2. Take the engagement read (analytics) Start with the broad picture, then narrow: 1. `analytics_community_health` for the overall level and direction over the period against the previous period. 2. `analytics_user_trends` for active users, new users and how they changed. Growth in new users with flat active users usually means sign-ups are not turning into participation. 3. `analytics_audience` for who is participating, by segment the community records. A health read that cannot say who the audience is has only half an answer. Do not write up a metric in isolation. A rise in posts that comes from a few very active users is a different finding from a rise spread across the base. ## 3. Take the content read (analytics, then search) 1. `analytics_content_performance` to see which content earns replies and views and which sinks with no response. Note the share of unanswered content, the single most useful engagement-quality signal. 2. Use `search_discussions` only to read the examples behind a finding, for instance two or three unanswered threads from a segment that the audience read flagged. Never use search to build the headline numbers; the analytics tools own the counts. ## 4. Take the load read (admin overviews) These are the work queues: 1. `admin_moderation_overview` for the moderation queue: how much is waiting, how old the oldest item is, and whether it is growing. A queue that is growing week on week is a staffing finding; a single old item is a process finding. 2. `admin_recognition_overview` for how recognition is being given. Concentration of all recognition on a few people is worth a line, not a headline. 3. `admin_user_overview` for membership health: the state of the user base as the admin view reports it. 4. `admin_community_structure` to check whether the spaces and categories that carry the most activity still match how the community is organised. Empty or dormant spaces are a structure finding. ## 5. Cross-check before ranking Each candidate finding needs confirmation from a second area before it goes to the top of the summary. Examples: - Unanswered content rising **and** moderation queue rising together points to too little staffing on the same spaces. - A drop in active users **and** a flat audience share points to a broad disengagement, not one segment leaving. - A strong content area with a weak structure entry suggests the content is succeeding despite the structure, which is a cheap fix. Findings confirmed by only one area go in "Watch", not "Act". ## 6. Rank into three tiers - **Act:** confirmed by two areas, and it either damages members' experience or blocks moderation. - **Watch:** a single-area signal, or a trend too short to trust (less than two periods). - **Noise:** movements within normal week-to-week variation, or effects of a known one-off such as a launch or holiday. Name these so the manager stops spending time on them. ## Common patterns and traps - **Vanity totals.** Post counts and registrations can rise while participation falls. Always pair a volume number with a breadth or response number. - **One loud segment.** A single very active group can make the whole community look healthy. The audience read is the check. - **Comparing unlike windows.** A month against a week is not a trend. Re-run the previous window of the same length before claiming change. - **Queue age, not queue size.** A large queue cleared daily is healthier than a small queue with items two months old. Look at age. - **Role blindness.** If some areas are missing, the review is partial. Say so at the top, not at the bottom. - **Treating search examples as evidence of scale.** Three threads show a pattern exists, not how big it is. Only the analytics counts size a finding. - **Content read or community read.** Sentiment in individual posts is not a health metric by itself. Report it as examples. ## Output ``` Community: Period: vs Role scope: