.png)
Client: Financial Therapy Association
Client Lead: Brandy Johnson
Industry: Professional Association / Certification
Transformation: Membership, Certification, Continuing Education, Events, Website & Reporting
Technology: Salesforce, WordPress, LearnDash, Paid Memberships Pro, Gravity Forms, Stripe, Accredible + custom integrations
When the Financial Therapy Association (FTA) came to us, the organization wasn't in crisis. Members were joining. Events were happening. Certification candidates were becoming Certified Financial Therapists. Emails were going out. Documents were being filed. From the outside, everything worked. But behind the scenes, keeping everything working required a tremendous amount of manual effort. Certification progress had to be monitored, follow up with applicants, manage documents, move information between systems, and make sure the next step happened when it was supposed to happen. The processes worked, but in many cases, they worked because someone was there to keep them moving.
FTA's existing membership platform actually did membership pretty well. It handled applications, renewals, auto-renewals, events, and basic membership reporting. Certification was another story. The system could accept certification applications and payments, but it couldn't actually manage the certification journey. FTA needed to know whether someone was eligible, where they were in the process, whether they completed required education, whether they passed each section of the exam, whether they submitted their final application, and eventually whether they had completed the continuing education required to renew their credential. Much of that work was manual. The RFP described certification administration as "completely manual" and specifically called for automation around applications, eligibility, exam results, final applications, and the two-year renewal process.
And certification wasn't the only disconnected piece. The LMS didn't automatically process exam completion. The WordPress directory wasn't connected to MemberClicks allowing the member to update their own profile. Email lists had to be exported and imported between systems. The online community didn't know whether someone was actually an active member. FTA had technology. What it didn't have was a technology ecosystem. And whenever the systems couldn't talk to each other, a person had to stand in the middle and make up the difference. The systems weren't carrying the weight.
FTA's RFP initially looked like a technology selection and integration project. The organization wanted to move away from a patchwork of MemberClicks and Google Drive for certification and create a more centralized experience. They wanted better automation, unified data, system synchronization, and a better experience for members and certification candidates. Reading the RFP, I knew pretty quickly that we were going to need a new membership architecture. But I also knew something else: We weren't ready to build it yet.
We first needed to understand how FTA actually operated. That's why our original proposal included a Discovery and Blueprint phase before implementation. We mapped the certification and membership journeys, decided what information belonged in Salesforce versus WordPress, reviewed the existing data structure, and developed the integration and automation architecture. We also explicitly stated that the implementation cost and timeline would be reassessed after discovery. That last part became important. Because the more we learned, the more we realized we weren't just migrating software. We were rebuilding operations.
I love building. It's one of my favorite parts of this work because, in some ways, we get to be magicians. Someone can describe something that exists only in their head, and we can turn it into something they can actually log into and use. How amazing!? But that's also exactly why discovery matters. Building before you understand the process just lets you make the wrong thing faster. Certification became the clearest example of that during this project. The RFP told us what FTA needed at a high level: an initial application, exam, final application, continuing education tracking, and renewal. But those words didn't tell us how the entire certification lifecycle needed to operate. We had to unpack it:
What happens after someone applies?
What makes them eligible?
What happens when they don't clearly meet the eligibility requirements?
Who reviews that application?
What happens after approval?
When can they purchase the educational series?
When can they take the exam?
What happens if they fail one section?
What happens after they pass?
When does the final application become available?
What happens after they're certified?
And two years later, how do we know they've completed the continuing education necessary to renew?
Suddenly, we weren't talking about a few forms and some automated emails.
We were designing a lifecycle.
One of the most important things we did during discovery was stop looking at certification only from FTA's perspective. We also looked at it from the applicant's perspective. An applicant shouldn't have to understand FTA's internal processes to get certified. They should be able to log in and answer a few simple questions:
Where am I?
What have I completed?
What do I need to do next?
That thinking became part of the blueprint. The applicant user stories specifically called for a clear step-by-step process, automatically synchronized progress, clear next steps after milestones, and reassurance that nothing had been overlooked. We did the same thing for existing Certified Financial Therapists. They needed to know how many CEUs they had earned, what categories those CEUs belonged to, what they still needed, when their certification expired, and what they needed to do to renew. And administrators needed almost the opposite experience. They didn't need another dashboard telling them everything happening in the system. They needed the system to handle the routine work and bring them in when a human decision was actually necessary. Our administrator user story eventually said it perfectly: The administrator should be able to focus on cases requiring judgment instead of manual updates. That became one of the guiding principles of the build.
It would have been easy to say: "Let's put everything in Salesforce." And in an ideal world with an unlimited technology budget, we could have created the entire member and certification experience inside Salesforce Experience Cloud. But architecture isn't just about what is technically possible. It has to make financial and operational sense for the organization that's going to live with it after the consultants leave. FTA already had WordPress. WordPress could do much more than host web pages. We could extend it with existing plugins, build custom functionality where necessary, and create the front-end experience FTA needed without introducing significant per-user portal licensing costs. So we divided responsibility intentionally.
WordPress would own the customer experience.
Salesforce would own the operational truth and certification logic.
The original proposal described WordPress as the member-facing platform and Salesforce as the operational backbone. That simple architectural decision shaped almost everything that came next. Today, membership and certification operate as distinct but connected systems. Users can share accounts across both experiences, directory visibility can respond to their status, certification can exist independently of membership, and Salesforce provides comprehensive tracking across the ecosystem.
One of the biggest things FTA was missing before the project was the ability to see someone's entire relationship with the organization.
Is this person a member?
Are they a Certified Financial Therapist?
Did they attend the conference?
Are they working through certification?
Did they pass the exam?
When does their certification expire?
Have they completed their CEUs?
Those answers shouldn't require opening multiple systems and searching someone's email address. Salesforce became the connective tissue. FTA's data model now connects a person to memberships, certification applications, forms, course enrollments, assessment results, certifications, CEU submissions, orders, event participation, and other engagement data. That's what we mean when we talk about a single source of truth. It isn't about cramming everything into one piece of software. It's about knowing where the truth lives and making sure the other systems know how to find it.
This was the heart of the transformation.
Today, the certification process spans:
Across that process, Salesforce handles much of the orchestration: creating and connecting records, evaluating eligibility, triggering special review, processing exam results, controlling access to subsequent stages, aggregating committee decisions, sending communications, and advancing the certification process. Before this project, FTA had to continuously check where people were in the process and follow up accordingly. Now, staff involvement is concentrated around the places where their judgment matters most—particularly application review and approval decisions.
We knew migration would be complicated. The blueprint even called migration one of the most complex phases of the project because membership, certification, CEUs, payment history, and directory visibility were interconnected. Our migration plan included applicants, existing CFTs, current members, directory data, historical orders, events, and CEUs. We planned for records. What we didn't plan well enough for was motion.
Membership history was relatively straightforward.
Event history was straightforward.
Order history was straightforward.
Certification wasn't.
Because people weren't just "applicants" or "certified."
Somebody had submitted their initial application.
Someone else had been approved but hadn't purchased the educational series.
Another person was halfway through the videos.
Someone had finished the videos but hadn't taken the exam.
Someone else had passed the exam and was preparing the final application.
We weren't just migrating people. We were migrating people who were standing at different points inside a process. And shortly after go-live, the real world found the gap. We started receiving messages from people who couldn't access the next thing they were expecting to complete. So we went back. We reviewed certification activity going back through 2025, figured out where active candidates actually belonged in the new journey, and got them where they needed to be. That experience changed the way I think about migrations. Don't just ask what records need to move. Ask: What processes are currently in motion, and where is each person standing inside them? That's a very different migration question.
There was another moment during this project that reinforced something I've come to believe about digital transformation. FTA also wanted to bring its shop experience into the new ecosystem. Technically, we could have. But we were already rebuilding membership, certification, learning, events, payments, directories, integrations, and reporting. Adding e-commerce would have introduced another major component into an already complex architecture—particularly around Stripe and payment processing. So we didn't. Not because it couldn't be done. Because everything doesn't have to be done at once. Daniel Kahneman's Thinking, Fast and Slow helped me get comfortable with something I used to struggle with: I don't have to have an immediate answer to every problem. My fast answers usually come from things I've seen or solved before. Complex problems require me to slow down, think deeply, question my first answer, and sometimes simply say, “I need to think about that.” I've started applying that same thinking to digital transformation. Move slow enough to think. Move fast enough to learn.
Because I don't care how experienced the implementation team is or how beautiful the process map looks: The first time real people start using your system, they're going to teach you something. You can make the perfect plan. Production doesn't care. People will click things you didn't expect them to click. They'll enter information you didn't expect them to enter. They'll be standing in places inside your process that you didn't realize existed. Those moments aren't proof that the transformation failed. They're where the transformation becomes real. The question is whether you've built your technology—and your implementation relationship—to adapt.
The biggest outcome of this project isn't Salesforce. It isn't WordPress. It isn't LearnDash, Stripe, Gravity Forms, or any of the other technology involved. It's that the technology now carries more of the operational weight. FTA can track certification pipeline activity, exam outcomes, CEU compliance, learning engagement, membership status and membership tiers, and directory participation. Certified professionals have a defined experience for seeing certification dates, renewal deadlines, CEU progress and requirements, submitting external CEUs, reviewing submission history, and paying renewal fees. Certification candidates have a defined journey. Staff have visibility into that journey. Automation handles much of the movement between steps.And FTA now has a structured certification renewal process supporting a revenue stream that its previous technology couldn't adequately support. But maybe the biggest change is simpler than all of that: No one person has to be the integration anymore.
At Quantum Leap Consulting we help nonprofits and associations untangle complex operations before turning them into technology. We specialize in Salesforce-centered ecosystems, process automation, integrated WordPress experiences, and the discovery work required to make all of it make sense.
Because the goal isn't to give your team another system to manage. It's to build a system that helps manage the work.
