Tiered Membership Design for Seattle REconomy

Early discussions with leadership explored a point-based system in which each tool would be assigned a value that resulted in corresponding "points" earned upon return. High-demand, high-value items would require high points to check-out. However, this system could unnecessarily penalize trustworthy, existing members.

To minimize disruption to the existing membership base, and because a disproportionate share of thefts occurred during a member's first checkout, we narrowed our focus specifically to new members.

Aligning this project with REconomy's ethos of access, we opted for the lightest-touch solution available. We simplified the model into a two-tier system: new members gain full access to most items immediately, and access high-demand, high-risk items after their initial checked-out items are returned.

To inform our approach to membership structure, I researched checkout policies and naming conventions used by other tool libraries. Checkout policies varied widely in complexity, ranging from unrestricted models to structured, milestone-based systems. One library limited first-time borrowers to two tools, then ten (with three or fewer power tools) after a successful first return.

Naming conventions for membership tiers were similarly varied across organizations, including pairings such as Easy Access / Full Access, Limited Access / Full Access, Guest / Full Member, and Pending / Active. None of the existing conventions I found aligned with Reconomy's emphasis on inclusive, non-hierarchical language.

To address this gap, I used Claude AI to ideate additional naming options, then evaluated these alongside my research findings against Reconomy's language priorities. New Member and Member emerged as the strongest fit and was the convention ultimately selected.

To parse which tools should be tier 1 or tier 2, I compiled and cross-referenced checkout data in Google Sheets that I exported from MyTurn.

I anonymized user data to protect member identities while preserve a record of their behaviors. I compiled additional reports to calculate, per item: usage rate (items checked out as a proportion of total available inventory) and theft rate (thefts as a proportion of total checkouts for that item, year-to-date).

Using these metrics, I defined a threshold for high-risk classification: an item qualified as high-risk if usage was ≥90% and theft rate was ≥10%, or if theft rate alone exceeded 80% regardless of usage. This dual-metric approach ensured that high-demand items with even moderate theft exposure were flagged, while also capturing outlier items with disproportionately high theft regardless of demand.

Each item was later cross-checked against member survey responses and pending tier assignments to validate alignment between data-driven risk classification and existing team intuition before finalizing the Tier 2 item list.

After presenting my findings to leadership, the majority of items were organized into tiers. However, a subset of items fell near the threshold on our risk metrics or lacked consensus. Instead of resolving edge cases unilaterally, we brought them to the membership via survey, treating members' collective judgment as deciding input for these classifications. Because we also needed feedback on naming and the policy in general, the survey included:

‍Item classification: Members were asked to sort ambiguous items into Tier 1 or Tier 2, and to flag any additional items they felt warranted Tier 2 status but hadn't yet been considered.

‍Language validation: We were sensitive to the risk of the language feeling punitive, distrustful, or hierarchical. Using likert scales, I asked about the tentative naming conventions—tier 1, tier 2, new member, and member—and added open-ended follow-up questions inviting alternative suggestions from those who ranked these as low-comfort terms.

‍Policy buy-in: The survey was anonymous and members were asked directly whether they supported the proposed policy change and why, along with an open field for general feedback.

Survey responses provided clear direction on the remaining ambiguous items. Leadership chose a 60% threshold as the tipping point where respondent votes for tier 2 would classify items as tier 2. This approach allowed member judgment to directly inform final classifications.

Language comfort scores were strongly positive. The "New Member" and "Member" labels scored particularly well, with all respondents rating comfort at 4 or 5 out of 5. The "Tier 1" and "Tier 2" labels skewed comfortable overall. A few respondents suggested alternative framings, such as limited / unlimited or qualitative, less clear, language. Those respondents indicated the existing terms were fine.

Support for the policy change overall was strong, with most respondents expressing support. However, several responses converged on the same underlying concern: less about whether to implement the policy, and more about how. Respondents consistently emphasized the need for clear procedures — specifically around how front desk volunteers should communicate the policy to members, how to handle exception requests, and how future changes to Tier 2 items would be documented and communicated. This feedback shifted our focus for the next phase of the project from finalizing classifications toward building the operational and communication scaffolding needed to support a smooth rollout.

Building on the survey findings and underlying risk data, I authored a formal proposal recommending the two-tier borrowing system be implemented as a policy. The proposal outlined the rationale for the change, the mechanics of the tiered access system, the finalized Tier 2 tool list derived from our risk analysis and survey input, and a phased rollout plan.

The proposal was submitted to REconomy's trustees for review and is currently pending approval.

‍A Note on Scope: Survey respondents raised a clear need for a volunteer communication script, a documented exceptions process, and a change-management procedure for future Tier 2 additions. This work is intentionally sequenced after trustee approval rather than before it: building out detailed operational policy for a system that hasn't yet been formally approved risks wasted effort if the proposal is revised or rejected outright. Once trustee feedback is incorporated, this case study will be updated to reflect the finalized language and procedural rollout.