When the Product Was the Problem
Designing a tiered engagement model for a 15-partner network with no margin for churn.
The Network
For two years I sat inside the backbone of a federally-funded community initiative — a network of fifteen community-based partner organizations bound together by a single shared reporting framework. The framework was the product I owned. Partners did not love it.
Most were small, scaling-phase nonprofits with limited data capacity. They weren't paying customers; they were sub-grantees, which gave the relationship compliance teeth. Reporting was the deliverable the funder paid for. A partner walking didn't open a renewal conversation — it eroded the federal grant funding the network. Churn was revenue loss, denominated in grant dollars instead of ARR.
The network had launched with twenty partners. By the time I arrived, five had dropped. Each lost partner meant lost services to the neighborhood and gaps in the data the funder was paying for.
This was one of roughly twenty-five concurrent projects I managed at any given time. The others ran on city departments, executives, boards, internal staff across seven departments, and our compliance overseer — all of whom also needed something from me. Partner retention had to happen inside that wider load.
The System
Tiered engagement by risk and capacity
I designed a tiered engagement model that assigned each partner a touch level based on two variables: churn risk and data capacity. The question was simple: How much support does this partner need to stay in the network and continue reporting?
Most customer success orgs segment by revenue first and layer touch model on top. That logic didn't apply here — the partners weren't revenue-differentiated. So the segmentation went straight to the variables that actually predicted retention.
Partners with leadership turnover, no dedicated data staff, or a track record of missed reporting cycles. The orgs most likely to drop.
Weekly or biweekly 1:1s. Listening sessions before any new ask. Direct hands-on support during reporting deadlines.
Annotated templates, walked-through documents, ad-hoc trainings calibrated to wherever the partner was stuck that week.
The partners most likely to leave got the most of my time. The relationship was the retention mechanism — not the framework, not the dashboard.
Partners who knew the framework and occasionally needed translation. Capacity was growing but uneven; most of the network lived here.
Monthly check-ins, structured email campaigns, regular office hours attendance, and ad-hoc 1:1 when something surfaced.
Reporting checklists, deadline calendars, network-wide resources, and shared dashboards. Light personalization on top.
The system did most of the work. I checked in to surface friction before it became risk — and pulled partners up to Tier 1 when something changed.
Partners with mature internal data infrastructure, or orgs that had been in the network long enough to operate independently.
Plenary meetings, optional office hours, asynchronous communication. Light contact by design.
Standard network resources. They pulled what they needed; the system stayed out of their way unless they pulled it in.
Protecting their time protected mine. Treating sophisticated partners as sophisticated kept the relationship clean.
Movement between tiers
Partners moved up when something changed — leadership turnover, capacity loss, a missed reporting cycle. They moved down when they stabilized or matured. The tier was a current read, not a label.
The model was built to scale the relationship work across a load I couldn't otherwise hold. Office hours and plenaries did one-to-many work. Email campaigns and self-serve materials did tech-touch work. That freed up one-to-one time for the partners where one-to-one was the only thing that would keep them in.
What Held
The infrastructure underneath the retention number — shared metric definitions, partner-facing dashboards, co-built governance documents — mattered. But the cleanest signal is the simplest one. None of the fifteen walked.
Where It Maps
The work was customer success in everything but name.
The vocabulary was different — partners instead of accounts, sub-grantees instead of customers, compliance instead of contracts. The architecture is the same.
The book was fifteen accounts. The complexity per account was enterprise-equivalent — each partner had its own executive director, board, program staff, compliance obligations, and political stakes, and partner churn meant grant erosion rather than a missed renewal: the nonprofit equivalent of lost ARR. The system I designed for fifteen was built to scale; the principles hold at seventy or one hundred fifty. What changes is the ratio of one-to-one to one-to-many — and the architecture already optimizes for that.