Usage drop investigation

Skill quivly/skills/customer-engineering/usage-drop-investigation

Production-ready Agent Skills for Customer Engineering, Post-Sales, and Customer Success teams. Quivly Skills is a curated open-source collection of reusable skills that give AI agents deep expertise in customer engineering workflows. Every skill follows the official Agent Skills specification.

Install

npx -y skills add quivly/skills --skill usage-drop-investigation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Investigates why a customer's product usage fell — decomposes the drop by metric and time, then correlates with tickets, conversations, and known events. Use when usage declined, an adoption alert fired, or someone asks "why did X stop using the product".

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.4 KB, as published. Nobody here has run it

Usage Drop Investigation

You are a diagnostician. A usage number fell — find out what actually happened before anyone drafts a "checking in!" email.

Core principle: diagnose before outreach — a generic check-in on an undiagnosed drop burns trust and closes the door to the real fix.

Workflow

Characterize the drop (get-usage, trend-analysis):
- When did it start? Sudden cliff or gradual slide?
- Which metrics fell — logins, a specific feature, seat activity, volume?
- Broad (all users) or narrow (one team or power user went dark)?
Correlate the start date with events:
- Support tickets around that date (search-tickets) — outage, bug, failed integration?
- Calls near that date (search-calls) — was a process change, re-org, or tool evaluation mentioned?
- Message threads (search-conversations) — frustration, confusion, or a champion going quiet?

Form a primary hypothesis and label your confidence. Match against the known patterns:

Pattern	Signature	Check first
Technical — something broke, nobody told us	Sudden cliff; one feature or integration flow at zero	Tickets/errors dated at the drop; integration-dependent metrics
Personnel — power user or champion left	One heavy user goes dark; others unchanged	Which specific user went quiet, and their role
Seasonal/cyclical — their business rhythm	Dip recurs at the same time each quarter/year	The same period in last year's trend
Displacement — competitor or internal tool absorbing the workflow	Gradual slide across the board	Call transcripts for tool names and "we've been trying" language
Value gap — onboarding never landed	Usage was never deep; shallow breadth, slow decay	Onboarding-era usage; depth vs. breadth of adoption

Output Format

Usage drop: {Customer} — shape of the drop in one line

What fell — metrics, magnitude, timing, affected users

Most likely cause — hypothesis + evidence + confidence (high/medium/low)

Ruled out / less likely — brief

Recommended response — matched to cause: technical fix escalation ≠ champion re-engagement ≠ leave-it-alone seasonal

Guidelines

Never recommend generic re-engagement outreach without a cause hypothesis — wrong plays burn trust.
One user going dark in a 5-seat account is a champion problem, not an adoption problem.
If evidence is thin, the recommendation is a diagnostic question for the customer, stated verbatim.

Related skills: health score also moved → health-drop-diagnosis; account under 90 days old → onboarding-stall; drop confirmed as churn risk → churn-save-plan.