A renewal workflow for course memberships with Stripe and GoHighLevel

Course subscriptions rarely end with a dramatic cancellation notice. More often, a member stops engaging, reaches a renewal date, and leaves without telling you why. A useful renewal workflow cannot guarantee retention. It can make sure the right people receive a relevant check-in before that date, and that nobody gets a renewal prompt after their plan has changed.

A practical stack uses Stripe as the billing record, Make to pass events between systems, and GoHighLevel as the CRM and follow-up layer. Proficiency Workflow builds custom CRM systems and automations and integrates Stripe, Make and GoHighLevel. The exact setup depends on the course platform and the account’s existing data; the workflow below is a pattern to configure and test, not a promise of a one-click recipe.

Start with one reliable renewal date

Before building messages, decide which system owns each fact. Stripe should be authoritative for whether a subscription is active, canceled or renewed, and for its next billing date. GoHighLevel can hold the contact record and the operational fields needed for follow-up. Make passes changes between them.

Connect a Stripe customer to a GoHighLevel contact with a stable identifier, such as the Stripe customer ID stored on the contact. Email can help with matching, but it should not be the only key: members change email addresses, and duplicate CRM contacts can produce crossed records. Define how to resolve a missing or ambiguous match before allowing the automation to send messages.

For course status, use a separate source if the learning platform can provide one. A renewal reminder is more useful when it reflects whether a member is active, stalled or finished. The same distinction matters in setting a clear rule for course completion and stalled learners.

Wire events through Make

1. In Stripe, identify the subscription events needed for the workflow. An upcoming invoice event can signal an approaching renewal; subscription updates can indicate a changed period or status; a paid invoice can confirm that billing succeeded. Include cancellation or deletion events so the CRM can stop future renewal outreach.

2. Send those events to a Make webhook scenario. In the scenario, identify the event type, find the related Stripe customer and subscription, then match the customer to the GoHighLevel contact. If the webhook payload does not provide every field needed, retrieve the current subscription details before updating the CRM.

3. Write only the fields the workflow needs: subscription status, plan or product, next renewal date, and the last event or update time. Keep the Stripe customer and subscription identifiers with the CRM record. Use event identifiers or another deduplication check so a repeated delivery does not create duplicate contacts or start the same sequence twice.

4. On a renewal, cancellation or plan change, update the record and recalculate its next action. Do not treat a webhook arrival as proof that the old CRM date is still correct. Events can arrive late or out of order, so check the current subscription state before sending a message.

Build the engagement sequence around the billing cycle

For an annual plan, a team might choose a check-in 30 days before renewal, a second message a week before, and a final note shortly before billing. Those intervals are starting points, not universal rules. Monthly plans may need a shorter sequence or just one timely message. Confirm that the timing fits the terms members accepted and any applicable notice requirements.

Use the renewal date stored from Stripe to create the schedule. One approach is for Make to check upcoming dates on a regular schedule and trigger the GoHighLevel follow-up; another is to use a CRM automation after the date is written. Either way, make the send conditional on the subscription still being active, the renewal date still matching, and the member not having already renewed or opted out.

Keep the messages useful rather than disguising a sales pitch as a billing notice. A first check-in can ask whether the member is getting value and point to a relevant course milestone. A later note can explain what continues with membership and how to manage the subscription. If a member has stopped progressing, offer help or a clear next step instead of assuming they need another reminder to pay. For auto-renewing subscriptions, do not imply that a member must take action to renew when no action is required.

Test the failure paths before launch

Test at least four cases: an active member approaching renewal, a member whose plan changes, a cancellation before a scheduled message, and a successful renewal. Confirm that a late or duplicate event does not restart the sequence. Confirm also that a contact with no reliable match is held for review rather than sent a message intended for someone else.

Failed payments need a separate branch. They are not the same as a member who is disengaged or about to renew, and they should not receive both a recovery sequence and a routine renewal sequence. Keep the billing status current and suppress the wrong messages when a payment issue occurs.

The trade-off is maintenance. Stripe, Make and GoHighLevel can keep billing events and follow-up connected, but the connection needs monitoring, clear ownership of fields and a process for exceptions. A date-only sequence is relatively simple, but it cannot tell whether a learner is making progress. Adding course activity can improve relevance, while also adding another integration and another source of data to reconcile. Start with accurate billing state and a small, testable sequence; add engagement rules only when the course data is dependable.