Findings sat in the backlog with no status change for two weeks, these are the ones losing money silently.
At a glance
The number of open Basecamp to-dos in the Vortex IQ Findings list whose updated_at has not changed in 14+ days. On Basecamp this card carries more weight than on richer PM tools, because Basecamp does not give the team any other staleness signal (no priority field, no last-touched warning, no auto-reminders). If this number climbs it is the single most reliable signal that operational discipline is regressing on a Basecamp team.
Calculation
Calculated automatically from your Basecamp data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A 14-person UK ethical-cosmetics brand on Shopify, marketing-led with a single ops manager and a contract dev. They run two Basecamp projects: DTC Storefront (marketing + ops) and Wholesale Portal (a small B2B side). Snapshot taken on 18 Apr 26 at 10:00 BST.- Status is in warn, trending toward critical. 10 stale to-dos on a 14-person team is a meaningful queue-health regression. On Basecamp specifically, this is the card you need to read because the tool itself does not flag staleness anywhere in its UI.
- Both root causes are people-availability events, not capacity events. Marketing lead off sick, dev contract paused. The right action is not to staff up; it is to reassign the queue while the gap exists. Open Tickets by Assignee to see who else can carry the items.
- The Wholesale Portal cluster is the easier one to clear. Four findings on one project with a single root cause (dev paused) means either close them as Won’t Do if the supplier API decision changes the work, or reassign them as soon as the dev returns. Either way it is one decision, not four.
- The DTC Storefront cluster carries marketing-revenue risk. Six untouched meta/og-image findings since early April means roughly 4 weeks of organic-traffic regressions sitting in the queue. Pair this card with Google Search Console crawled-but-not-indexed counts to size the SEO impact.
- The right action is a 30-minute weekly triage. On a small team this is what stops staleness compounding. One ops lead walks the abandoned list, marks anything with no real merchant impact as completed (Basecamp does not have a Won’t Do state, so the team uses a comment + tick-complete pattern), and reassigns the rest. Most teams find 30-50% of stale findings should be closed-not-fixed.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Basecamp’s own UI:Basecamp does not natively expose an “abandoned” filter or any per-to-do staleness indicator. The closest manual equivalent is to open the project’s Activity feed (project home → Activity), scroll back two weeks, and look for to-dos that do not appear in the recent feed. This is genuinely awkward to do, which is why this card exists. A second-best option is to click into each open to-do in the Vortex IQ Findings list and read the Updates footer at the bottom of the to-do page; Basecamp shows the last edit time. Doing this 50 times by hand is the manual equivalent of the card.The honest read is: Basecamp does not surface this metric, on purpose, because the 37signals product philosophy holds that staleness should be addressed in human conversation rather than in tooling. We respect the philosophy by not writing a “stale” badge into Basecamp itself; we surface the count here, and the team is expected to act on it through their normal triage rhythm. Why our number may legitimately differ from a manual Basecamp staleness scan:
Cross-connector reconciliation. Basecamp abandoned vs incident-management peers:
Known limitations / merchant FAQs
Basecamp shows my to-do was edited yesterday but you say it’s abandoned. What’s wrong? Almost always one of two things. (1) The “edit” was a Basecamp-internal re-index after an account-admin change, which we do not treat as movement; we readupdated_at directly and a re-index does bump it temporarily but the connector cross-checks against the Updates footer on a 5-minute cadence and self-corrects. Open the to-do and check the Updates footer at the bottom; if there is no human action in the last 14 days, our count is correct. (2) Polling lag: an edit made in the last 5 minutes may not have reached us yet; refresh in 5 minutes.
What counts as movement?
Any of: assignee change, due-date change, comment posted, description edit, name edit, or completion. What does NOT count: someone opening the to-do to read it (Basecamp does not surface “viewed” events) and reordering the list (Basecamp treats reorder as a list-level operation that does not bump per-to-do updated_at).
The 14-day window feels arbitrary. Can we tune it?
Yes, in Settings → Connectors → Basecamp → Abandonment threshold (days). We default to 14 days because it sits one full sprint plus a buffer. Basecamp teams are typically smaller than ClickUp or Monday teams, and small teams sometimes prefer a tighter 7-day window because their personal involvement with each to-do is higher; agency teams running multi-week client projects sometimes prefer 21 days. The right setting is the shortest one your team can act on without false alarms.
We have multiple Basecamp accounts (one per agency client). The count looks alarming.
Open the per-account stack panel from the connector drawer to see which account is driving the abandoned count. Agencies typically find the count clusters on one or two accounts that have been drifting between active phases (e.g. a client between campaign cycles). The actionable view is which client to put on the next triage call.
Resolution rate dropped, abandoned rising. What changed?
Standard playbook: (1) Open Tickets by Assignee and look for sudden concentration changes, a key person leaving, going on leave, or pulled onto another project is the single most common cause. (2) Open Throughput Trend; a throughput dip preceding the abandoned spike means capacity dropped first. (3) Cross-check against Datadog incidents; a sustained incident burst pulls the team off audit work for days at a time. The combination usually identifies the cause within minutes.
The abandoned count appears suddenly higher overnight, even though no one was working. Why?
Because the 14-day clock keeps ticking even when no one is editing. If five to-dos were last touched on the same day exactly 14 days ago, all five become abandoned at the same time the next day. This is normal and corrects itself within 24 hours of the team picking the queue back up.
Should I close abandoned to-dos or fix them?
Both, depending on triage. Run a weekly 30-minute “abandoned review” with one ops lead. Basecamp does not have a Won’t Do state, so the convention is: post a comment on the to-do explaining the close decision, then tick complete. Most Basecamp teams find 30-50% of abandoned items should be closed-not-fixed; doing this triage once a week stops the queue compounding.
Is this the right card for my context, or should I focus on Findings Open?
On Basecamp specifically, this is the more important card. Findings Open tells you queue size; this card tells you queue health. Because Basecamp gives the team no other staleness signal natively, this card is doing work the tool itself does not. If you only watch one Basecamp findings card, watch this one. The open count can climb for healthy reasons (audit programme is finding more this week); a rising abandoned count almost never has a benign cause on a Basecamp team.
Why doesn’t Basecamp have a built-in “abandoned” view?
Because 37signals deliberately does not build it. The product philosophy holds that staleness signals encourage management busywork; teams should triage in human conversation instead. We respect this by routing Vortex IQ to one to-do list per project and surfacing the staleness rollup here in Vortex IQ Nerve Centre rather than asking Basecamp to produce one. The same applies to Trello (no abandoned filter), ClickUp (no abandoned filter), Monday (no abandoned filter), Linear (no abandoned filter); none of them ship an abandoned-task primitive, all of them have task-modification timestamps we can read.
Today’s count looks volatile. Why?
At low volumes (under 5 abandoned) a single “movement” event resets the timer on one to-do and drops the count by 20%. Over 7 days the trend smooths out; the headline number is the live count, the 30-day average shown beneath is the steadier read.