The Three Legs of Membership Software Implementation

The framework.

A working membership software implementation rests on three legs. Lose any one and the stool falls over. The legs aren't optional, and they aren't interchangeable.

Leg 1: your users. The lodge secretaries, treasurers, membership chairs, members. The people who use the software every day to do the actual work of the organization.

Leg 2: your staff. The Grand Secretary's office, your executive director, or whoever holds the institutional knowledge of how your organization actually operates. The people who answer the questions only your organization can answer.

Leg 3: your software vendor. The company that built and maintains the platform. The training, support, documentation, and platform know-how that lets users actually do their work.

Each leg has a job that no other leg can do. Each leg can fail in its own way. Most organizations have problems with their software because one of the three legs is too short, missing, or trying to do another leg's job.

Leg 1: your users.

Active users aren't users who "log in occasionally." Active users are members who actually do the work of the organization through the software. Enter member records, run reports, send communications, process payments, manage events, update statuses.

What this leg failing looks like: the secretary who keeps a private spreadsheet because the software is "too complicated." The treasurer who only logs in once a year to run the audit. The membership chair who emails new members from a personal account. The leg isn't broken because the people aren't capable. It's broken because the system has not been made theirs.

Why it matters: software that doesn't get used doesn't deliver value. An organization can have a perfect platform with perfectly trained admins and active vendor support, and still fail if the volunteer secretary isn't using the system to do their work. The data decays. The processes drift. Your people don't get the benefit.

The user leg is the hardest to get right because it's the most distributed. Every officer, every cycle, every chapter has to come along. There is no shortcut.

Leg 2: your staff.

Every organization has questions that only the organization itself can answer. In a Grand Body, those answers come from the Grand Secretary's office. In a single-organization context, they come from the executive director, the membership director, or whoever holds the institutional context.

What this leg answers: Why was this member granted a dispensation in 2019? What's the current rule on multi-membership? Who do we talk to about a transfer between jurisdictions? Was this lodge merger ever formally recorded? Is this individual eligible for a particular office? What's the policy on event registrations from non-members? When does dues delinquency trigger suspension? These aren't software questions. They're jurisprudence questions, organizational policy questions, institutional memory questions.

A software vendor can tell you how the system works. It cannot, and should not, tell you how your jurisdiction works.

What this leg failing looks like: the Grand Secretary's office is overwhelmed and stops returning calls. The executive director is part-time and doesn't have answers ready. Officers stop asking and start working it out on their own. The questions don't disappear. They just get answered worse, by people who don't have the authority or the context to answer them.

Why it matters: when leg 2 isn't active, leg 3 (the software vendor) gets pulled in to fill the gap. That's where most of the well-known software-implementation failures actually start. The vendor support desk ends up answering jurisprudence questions, often badly, and those answers harden into precedent nobody in the organization deliberately chose.

Leg 3: your software vendor.

The third leg is what you bought when you signed the contract. The platform itself, plus the training and support that turn it from "software that exists" into "software your people can actually use."

What this leg should provide: training that reaches every user, not just admins. A help desk that answers technical questions confidently, by people whose entire job is the platform. Documentation that's current. Onboarding that meaningfully migrates your data and configures the platform for how your organization works. Continuity, so the relationship doesn't restart every time an officer changes.

What this leg failing looks like: training is a 90-minute video from 2021 and a PDF nobody reads. Support is a ticket queue with multi-day response times. The vendor's account manager turned over twice last year. The platform gets updates, but nobody tells your users what changed. New officers can't find a way in.

Why it matters: even if leg 1 (active users) and leg 2 (active staff) are healthy, an inactive vendor leg means your users and staff are spending energy answering questions about the software that the vendor should be answering. The org becomes its own help desk for software it didn't build. ( The deeper diagnosis of how this fails is in another post in this series. )

How the stool actually breaks.

There are two distinct ways the stool fails, and naming both is the most useful thing a Grand Body or executive can do for themselves.

Failure mode 1: a leg is missing. The most obvious version. One of the three roles is inactive, and the stool falls over even if the other two are healthy.

Strong vendor and strong staff, weak users. The platform works perfectly, the executive director knows every answer, but most officers aren't trained or aren't using the system. Your people don't get the benefit because the work isn't getting done in the system.
Strong vendor and strong users, weak staff. Your users are active, the platform works, but nobody at the organization has authority to answer the policy and jurisprudence questions that come up. The questions get answered worse, by people who don't have the context.
Strong staff and strong users, weak vendor. Your people want to use the platform and your staff knows the answers, but the vendor support is unreachable, training is stale, and the platform itself is brittle. Your users start working around the system. The investment evaporates.

Failure mode 2: a leg is trying to do two jobs. The less obvious and more damaging version. The stool doesn't immediately fall, but it wobbles, the overloaded leg buckles, and the substituted-for leg atrophies further from disuse.

Software trying to be two legs. When the vendor's support desk gets pulled in to answer organizational and jurisprudence questions (often because the staff leg is weak), the vendor accepts the work, sometimes monetizes it as a Professional Services tier, and gives answers that calcify as organizational precedent without proper deliberation. Governance erodes quietly.
Grand Body trying to be two legs. When the Grand Secretary's office becomes the de facto software help desk (often because the vendor leg isn't reaching lodge users), the staff's actual job (institutional answers, governance, relationships) gets squeezed. They stop returning the calls about jurisprudence because they're answering tickets about how to run a report.

The point isn't that any one leg is more important than the others. It's that each leg can only do its own job, and asking any leg to do two jobs is the most reliable way to break the stool. Most of the time when an organization says "the software isn't working," the real problem is either a missing leg or a substituted leg.

A diagnostic for your own stool.

Five questions. Three about whether each leg is active, two about whether any leg is trying to do another's job.

Is each leg active?

Are your users active? Pick three officers at random across your organization. Ask them how often they log in, what they do when they're in there, and what they avoid because it's too hard. The honest answer tells you the state of leg 1.
Is your staff active? When a lodge secretary calls with a real organizational question (member status, transfer, policy), does the answer come confidently from the right person within a day? Or does the question get punted, deferred, or never quite resolved?
Is your vendor active? When a user has a software question, can they get a competent answer directly, fast, without escalating up to your overworked staff? If you don't know, ask. Vendors that can answer this well will tell you. Vendors that can't will dodge.

Is any leg doing two jobs?

Is your software vendor answering organizational questions? Look at recent vendor support tickets and ask whether any of them are really jurisprudence or policy questions that should belong with your staff. If so, that's the substitution. The vendor leg is doing the staff leg's job, badly.
Is your staff answering software questions? Look at recent calls or emails to your Grand Secretary's office or executive director. How many are software-mechanics questions that should have gone to the vendor? If the answer is "a lot," the staff leg is doing the vendor leg's job, and wearing out doing it.

If the answer to any of these is "no" or "I'm not sure," that's where the stool is wobbling.

How Groupable thinks about this.

Groupable was designed around the assumption that all three legs need to be supported, not just one. The platform itself is leg 3. We deliver on that leg by including end-user support for every user (not just admins) and roughly 100 training sessions a year, so volunteer officers actually have somewhere to go. ( See Groupable's pricing. )

We help orgs strengthen leg 1 (active users) by making the user experience competent enough that volunteer officers will actually use it, and by training reach that gets to the front lines, not just the admins who attended onboarding.

We respect leg 2 (active staff). The Grand Secretary's office or the executive director holds the institutional authority. We don't try to substitute for that. We try to give your staff better tools to exercise it.

The goal isn't to be a better outsourced brain. It's to give the organization the tools to keep its own.

A working membership organization isn't a piece of software. It's a stool. We try to be a strong third leg.

The Three Legs of a Membership Software Implementation: Why Two Out of Three Isn't Enough