Implementation Guide: Trigger enrollment renewal workflows for expiring student subscriptions

Hardware Procurement

Dell OptiPlex 7020 Micro Form Factor

Software Procurement

Prerequisites

• Client must have an active Teachworks account on the Growth plan or higher (required for API access) OR a TutorCruncher account with API access enabled — with at least 3 months of historical enrollment data migrated
• Client must have a registered business domain (e.g., brightsparktutoring.com) with DNS access for email authentication (SPF, DKIM, DMARC records) — Gmail/Yahoo addresses will not work for transactional email
• Client must have an active Stripe account (or be willing to create one) connected to their business bank account for automated payment processing
• Client must have documented parent/guardian consent for email AND SMS communications — a signed enrollment agreement that includes communication consent language, or a separate opt-in form
• Client must provide a designated administrative contact with login credentials to Teachworks, Stripe, and the business email system for API key generation and OAuth authorization during setup
• Stable broadband internet connection (minimum 25 Mbps download / 5 Mbps upload) at the tutoring center — all cloud workflows require reliable connectivity
• Client must provide a complete list of current subscription/enrollment term types offered (e.g., monthly, quarterly, semester, annual) with their respective pricing, so workflows can be configured with correct renewal amounts
• Existing student records in Teachworks must have the following fields populated: student name, parent/guardian name, parent email, parent phone number, enrollment start date, enrollment end date / subscription term, and current payment status
• MSP must have executed Data Processing Agreements (DPAs) with Teachworks, Make.com (or chosen workflow engine), Twilio/SendGrid, Stripe, and HubSpot before any student data flows through the automation
• If the tutoring center serves children under 13: verify COPPA compliance — all renewal communications must be directed to parent/guardian contacts only; no direct collection of data from minor students

Installation Steps

Step 1: Audit Client Environment and Enrollment Data

Before any technical work, the MSP technician must conduct a thorough audit of the client's current enrollment management practices. Log into the client's Teachworks account and document: (1) total active students, (2) subscription term types and pricing, (3) data completeness — what percentage of students have parent email, phone, and enrollment end dates populated, (4) current renewal process (manual emails? phone calls? nothing?), (5) any existing integrations. Export a CSV of all active enrollments and identify any data gaps that must be remediated before automation can work. This audit also serves as the baseline for measuring improvement.

Step 2: Provision Teachworks API Credentials

Generate API credentials in the client's Teachworks account to allow the workflow engine to query student enrollment data. Navigate to Settings > Integrations > API in Teachworks. Generate a new API key and secret. Document the base URL (https://api.teachworks.com/v1/) and test the connection with a simple GET request to verify access. The API provides endpoints for students, enrollments, invoices, and lessons.

curl -X GET 'https://api.teachworks.com/v1/students?per_page=5' \
  -H 'Authorization: Token token=YOUR_API_KEY'

Step 3: Set Up Twilio SendGrid for Transactional Email

Create a Twilio SendGrid account (or use the client's existing one), verify the client's business domain for email authentication, and create dynamic email templates for the renewal campaign. Domain verification involves adding CNAME records to the client's DNS for SPF, DKIM, and DMARC — this is critical for email deliverability and avoiding spam filters.

Step 4: Configure Twilio Programmable SMS

Set up Twilio SMS for parent/guardian text notifications. Purchase a local phone number, configure messaging service, and create SMS templates. SMS will be used for 7-day and expiration-day reminders only (not all stages) to balance urgency with cost and avoid message fatigue.

curl -X POST 'https://api.twilio.com/2010-04-01/Accounts/ACXXX/Messages.json' \
  -u 'ACXXX:AUTH_TOKEN' \
  -d 'To=+1XXXXXXXXXX' \
  -d 'MessagingServiceSid=MGXXX' \
  -d 'Body=Test: Your enrollment renewal reminder from [Client Name].'

Step 5: Set Up Stripe Billing for Automated Renewal Invoices

Configure Stripe Billing to generate renewal invoices with embedded payment links. Create product catalog entries for each subscription term type the tutoring center offers. Set up webhooks so Stripe can notify the workflow engine when a payment succeeds or fails.

Test with Stripe CLI:

stripe listen --forward-to https://hook.us1.make.com/XXXXXXX
stripe trigger invoice.payment_succeeded

Step 6: Provision HubSpot CRM Free Tier and Configure Renewal Pipeline

Set up HubSpot CRM with a custom deal pipeline specifically designed for tracking enrollment renewals. Each student approaching renewal becomes a deal that moves through defined stages, giving the center administrator a visual dashboard of the entire renewal pipeline.

Step 7: Create Make.com Account and Configure Core Scenario

Set up the Make.com account, create the master automation scenario, and configure the Teachworks API polling module that serves as the workflow trigger. The scenario will run on a daily schedule, querying Teachworks for all students whose enrollment end date falls within the next 30 days, then routing each student through the appropriate reminder stage.

# Teachworks API poll configuration

URL: https://api.teachworks.com/v1/students
Method: GET
Headers: Authorization: Token token=YOUR_TEACHWORKS_API_KEY
Query Parameters: status=active&per_page=100

# Formula to calculate days_until_expiration

dateDifference(now; student.enrollment_end_date; days)

• Route A: days_until_expiration = 30 → 30-day email reminder
• Route B: days_until_expiration = 14 → 14-day email reminder
• Route C: days_until_expiration = 7 → 7-day email + SMS
• Route D: days_until_expiration = 0 → Final notice email + SMS + generate invoice
• Route E: days_until_expiration = -1 → Mark as Lapsed in CRM

Step 8: Build 30-Day Email Reminder Route

Configure the Make.com route that fires when a student's enrollment is exactly 30 days from expiration. This route sends a friendly, informational email to the parent/guardian and creates a deal in HubSpot CRM at the 'Upcoming Renewal' stage.

Module A1: SendGrid > Send Email via Dynamic Template

• Connection: Create new SendGrid connection with API key
• To: {{student.parent_email}}
• From: renewals@clientdomain.com
• From Name: [Client Tutoring Center Name]
• Template ID: d-XXXXX30 (30-day template)

Dynamic Template Data (JSON) for Module A1:

{
  "parent_name": "{{student.parent_name}}",
  "student_name": "{{student.first_name}} {{student.last_name}}",
  "subscription_type": "{{student.subscription_type}}",
  "expiration_date": "{{formatDate(student.enrollment_end_date; 'MMMM D, YYYY')}}",
  "renewal_amount": "{{student.subscription_price}}",
  "renewal_link": "https://billing.stripe.com/p/login/XXXXX"
}

Module A2: HubSpot CRM > Create Deal

• Connection: Create new HubSpot connection with Private App token
• Pipeline: Enrollment Renewals
• Stage: Upcoming Renewal
• Deal Name: Renewal - {{student.first_name}} {{student.last_name}} - {{formatDate(student.enrollment_end_date; 'YYYY-MM-DD')}}
• Property — Student Name: {{student.first_name}} {{student.last_name}}
• Property — Parent Email: {{student.parent_email}}
• Property — Parent Phone: {{student.parent_phone}}
• Property — Subscription Type: {{student.subscription_type}}
• Property — Expiration Date: {{student.enrollment_end_date}}
• Property — Teachworks Student ID: {{student.id}}
• Property — Amount: {{student.subscription_price}}

Step 9: Build 14-Day and 7-Day Reminder Routes

Configure the 14-day email-only reminder route and the 7-day email+SMS reminder route. The 14-day reminder increases urgency slightly. The 7-day reminder adds SMS to the mix for higher visibility, as parents may have missed or ignored the email. Both routes also update the corresponding HubSpot deal stage.

Body: "Hi {{student.parent_name}}, {{student.first_name}}'s tutoring enrollment expires in 7 days ({{formatDate(student.enrollment_end_date; 'MMM D')}}). Renew now to keep their spot: {{renewal_link}} — [Client Name]"

Step 10: Build Expiration Day Route with Invoice Generation

Configure the final automated touchpoint: on the day of expiration (days_until_expiration = 0), the workflow sends a final notice email and SMS, generates a Stripe invoice with a 7-day payment link, and updates the CRM. This is the highest-urgency automated message and includes a direct payment link.

Route D: Expiration Day — Final Notice + Invoice Filter: days_until_expiration = 0

FINAL NOTICE: {{student.first_name}}'s tutoring enrollment expires today. Renew now to avoid losing their spot: {{invoice.hosted_invoice_url}} — [Client Name]

Step 11: Build Stripe Webhook Handler for Payment Confirmation

Create a separate Make.com scenario that listens for Stripe webhook events. When a parent pays the renewal invoice, the webhook fires and this scenario automatically updates the CRM deal to 'Renewed', sends a confirmation email and updates Teachworks with the new enrollment end date.

PUT https://api.teachworks.com/v1/students/{{student_id}}
{ "enrollment_end_date": "NEW_DATE_BASED_ON_SUBSCRIPTION_TYPE" }

Step 12: Build Lapsed Student Handler

Configure the route that handles students who have not renewed by the day after expiration. This route marks the CRM deal as 'Lapsed', optionally suspends future lessons in Teachworks, and adds the student to a win-back list for the center admin to pursue manually.

# PUT https://api.teachworks.com/v1/students/{{student_id}}

{ "status": "inactive" }

Step 13: Configure Email Templates in SendGrid

Create the five dynamic email templates in SendGrid's Design Editor. Each template should be mobile-responsive, brand-consistent, CAN-SPAM compliant, and include dynamic handlebars for personalization. Work with the client to finalize copy and design.

Step 14: Implement De-duplication and Idempotency Logic

Because the workflow runs daily, it must not send duplicate reminders to the same parent for the same renewal cycle. Implement de-duplication by checking HubSpot deal stages before sending any communication. If a deal already exists at or beyond the current reminder stage, skip that student for that route.

This prevents: multiple deals for the same student renewal, re-sending a 30-day email if the student already got a 14-day, and sending any reminder if the student already renewed.

Step 15: Enable Error Handling, Logging, and MSP Alerting

Configure comprehensive error handling in Make.com so the MSP is immediately notified of any workflow failures. Set up break/retry handlers on each module, configure Make.com's built-in email notifications for scenario errors, and set up a dedicated monitoring webhook to the MSP's alerting system (e.g., PagerDuty, Slack, or email).

Step 16: End-to-End Testing in Staging Environment

Before going live, conduct comprehensive testing with synthetic student records. Create 5–10 test students in Teachworks with enrollment end dates set to trigger each workflow route (30 days out, 14 days out, 7 days out, today, and yesterday). Run the scenario manually and verify every module fires correctly, every email is received, every SMS is delivered, and every CRM update is accurate.

Stripe test card: 4242 4242 4242 4242

Step 17: Go-Live: Switch to Production and Activate Scheduled Scenario

After successful testing, transition all connections to production credentials, activate the Make.com scenario on its daily schedule, and monitor the first three execution cycles closely for any issues.

Custom AI Components

Enrollment Expiration Date Calculator

Type: workflow A Make.com function module that calculates the number of days between the current date and each student's enrollment end date, accounting for timezone differences. This is the core logic that determines which workflow route each student enters. While simple arithmetic, it must handle edge cases: null dates, past dates, timezone offsets, and date format variations from the Teachworks API.

Variable: days_until_expiration

{{if(student.enrollment_end_date; floor(dateDifference(formatDate(now; "YYYY-MM-DD"; "America/New_York"); formatDate(student.enrollment_end_date; "YYYY-MM-DD"; "America/New_York"); "days")); -999)}}

• student.enrollment_end_date — the expiration date from Teachworks API
• now — current timestamp in Make.com
• Both dates are formatted to YYYY-MM-DD in the client's timezone (adjust America/New_York to the client's actual timezone) to avoid partial-day calculation errors
• dateDifference() returns the integer number of days between the two dates
• floor() rounds down to ensure we don't trigger a day early
• The outer if() handles null/missing enrollment_end_date by returning -999, which matches no route filter and causes the student to be skipped (logged as a data quality issue)

Router Filters

• Route A filter: {{days_until_expiration}} = 30
• Route B filter: {{days_until_expiration}} = 14
• Route C filter: {{days_until_expiration}} = 7
• Route D filter: {{days_until_expiration}} = 0
• Route E filter: {{days_until_expiration}} = -1

Edge Case: Students who enroll mid-cycle

Teachworks API Paginated Fetcher

Type: integration

A Make.com sub-scenario (reusable module) that handles paginated retrieval of all active students from the Teachworks API. The Teachworks API returns a maximum of 100 records per page, so tutoring centers with more than 100 active students require pagination. This component loops through all pages and aggregates the complete student list before passing it to the main workflow.

Make.com Scenario: Teachworks Paginated Fetcher

Module Flow

Inside the While Loop, configure the following modules:

• HTTP > Make a Request: Method: GET, URL: https://api.teachworks.com/v1/students, Headers: Authorization: Token token={{TEACHWORKS_API_KEY}}, Query Params: status=active&per_page=100&page={{page}}
• Array Aggregator: Append response items to all_students
• Set Variable: page = {{page + 1}}
• Filter/Break: If response array length < 100, set has_more = false → exit loop

GET https://api.teachworks.com/v1/students
Authorization: Token token={{TEACHWORKS_API_KEY}}
?status=active&per_page=100&page={{page}}

Implementation Notes

• Make.com does not have a native while loop; implement using the Repeater module set to a maximum of 50 iterations (supports up to 5,000 students) with a Break error handler
• Each page request counts as 1 Make.com operation; a center with 500 students uses 5 operations for pagination
• Add a 500ms Sleep module between page requests to respect Teachworks API rate limits
• Filter the aggregated array for students with enrollment_end_date within the next 31 days AFTER aggregation to minimize downstream processing

New Enrollment End Date Calculator

Type: workflow

A calculation module used in the Stripe payment webhook handler that determines the new enrollment end date when a student renews. It takes the current expiration date and adds the appropriate number of days based on the subscription type. This is critical for correctly updating Teachworks after a successful payment.

Make.com Formula Implementation

Used in the Stripe Webhook Handler scenario, Module A3 (Teachworks enrollment update).

Step 1: Extract subscription type from Stripe invoice metadata

When creating the Stripe invoice (in the main scenario, Module D1c), include metadata:

{
  "metadata": {
    "teachworks_student_id": "{{student.id}}",
    "subscription_type": "{{student.subscription_type}}",
    "current_end_date": "{{student.enrollment_end_date}}"
  }
}

Step 2: In the webhook handler, calculate new end date

Set Variable module formula:

{{switch(
  event.data.object.metadata.subscription_type;
  "monthly"; addDays(event.data.object.metadata.current_end_date; 30);
  "quarterly"; addDays(event.data.object.metadata.current_end_date; 90);
  "semester"; addDays(event.data.object.metadata.current_end_date; 150);
  "annual"; addDays(event.data.object.metadata.current_end_date; 365);
  addDays(event.data.object.metadata.current_end_date; 30)
)}}

Step 3: Format for Teachworks API

{{formatDate(new_end_date; "YYYY-MM-DD")}}

Duplicate Deal Prevention Filter

Type: workflow A reusable filter pattern applied at the start of each reminder route to prevent duplicate communications. It queries HubSpot for existing deals matching the student and evaluates whether the current reminder stage has already been processed. This ensures idempotent execution even if the main scenario runs multiple times per day or encounters retries.

Implementation

Module: HubSpot CRM > Search Deals

• Group 1: student_teachworks_id equals {{student.id}}
• Group 2: pipeline equals Enrollment Renewals
• Group 3: dealstage is not closedwon (Renewed)
• Group 4: dealstage is not closedlost (Lapsed)

Post-Search Filter Logic (Make.com Filter between modules)

For Route A (30-day): Condition: Number of bundles from HubSpot search = 0 Label: "No existing deal — proceed to create" If a deal already exists for this student in this renewal cycle, skip entirely.

For Route B (14-day): Condition: Number of bundles > 0 AND deal.dealstage IN ["upcoming_renewal", "30_day_reminder_sent"] Label: "Deal exists and is at or before 30-day stage — proceed to 14-day"

For Route C (7-day): Condition: Number of bundles > 0 AND deal.dealstage IN ["upcoming_renewal", "30_day_reminder_sent", "14_day_reminder_sent"] Label: "Deal exists and is before 7-day stage — proceed"

For Route D (expiration day): Condition: Number of bundles > 0 AND deal.dealstage NOT IN ["invoice_sent", "closedwon", "closedlost"] Label: "Deal exists and invoice not yet sent — proceed"

For Route E (lapsed): Condition: Number of bundles > 0 AND deal.dealstage = "invoice_sent" Label: "Invoice was sent but not paid — mark as lapsed"

Additional Safety: Execution Deduplication Key

In each email/SMS sending module, append a dedup key to the SendGrid custom_args or Twilio StatusCallback:

dedup_key: {{student.id}}_{{formatDate(now; "YYYY-MM-DD")}}_{{route_name}}

This allows post-hoc auditing to verify no duplicates were sent on any given day.

Weekly Renewal Pipeline Summary Report

Type: workflow

A standalone Make.com scenario that runs every Monday morning and generates a summary report of the renewal pipeline, including counts by stage, renewal rate percentage, revenue renewed vs. at-risk, and a list of students requiring manual follow-up. The report is emailed to the client administrator and the MSP account manager.

Implementation:

Make.com Scenario: Weekly Renewal Summary

Schedule: Every Monday at 8:00 AM client timezone

Module Flow

Module 1: HubSpot > Search Deals

• Pipeline: Enrollment Renewals
• Create Date: last 7 days
• Return all deals

Module 2: Array Aggregator

• Group by: dealstage
• Count deals in each stage

Module 3: Set Variables — Calculate Metrics

total_deals = count of all deals created or updated in last 7 days
renewed_count = count where dealstage = 'closedwon'
lapsed_count = count where dealstage = 'closedlost'
pending_count = total_deals - renewed_count - lapsed_count
renewal_rate = (renewed_count / (renewed_count + lapsed_count)) * 100
revenue_renewed = sum of deal amounts where stage = closedwon
revenue_at_risk = sum of deal amounts where stage != closedwon and stage != closedlost

Module 4: SendGrid > Send Email

• To: admin@clientdomain.com, msp-account-manager@mspcompany.com
• Subject: Weekly Enrollment Renewal Report — {{formatDate(now; 'MMM D, YYYY')}}

<h2>Enrollment Renewal Pipeline — Weekly Summary</h2>
<table>
  <tr><td>Total Active Renewal Deals</td><td>{{total_deals}}</td></tr>
  <tr><td>✅ Renewed This Week</td><td>{{renewed_count}}</td></tr>
  <tr><td>❌ Lapsed This Week</td><td>{{lapsed_count}}</td></tr>
  <tr><td>⏳ Pending (In Pipeline)</td><td>{{pending_count}}</td></tr>
  <tr><td>📊 Renewal Rate</td><td>{{renewal_rate}}%</td></tr>
  <tr><td>💰 Revenue Renewed</td><td>${{revenue_renewed}}</td></tr>
  <tr><td>⚠️ Revenue At Risk</td><td>${{revenue_at_risk}}</td></tr>
</table>

<h3>Students Requiring Manual Follow-Up</h3>
<p>The following students have lapsed and did not respond to automated outreach:</p>
<ul>
  {{#each lapsed_students}}
  <li>{{student_name}} — Parent: {{parent_name}} ({{parent_phone}}) — Expired: {{expiration_date}}</li>
  {{/each}}
</ul>

<p><a href='https://app.hubspot.com/contacts/PORTAL_ID/objects/0-3/views/all/list'>View Full Pipeline in HubSpot →</a></p>

Testing & Validation

Client Handoff

The client handoff should be conducted as a 60–90 minute session with the tutoring center's designated administrator(s), covering the following topics:

Documentation to Leave Behind

• System architecture diagram (1 page)
• HubSpot CRM quick-reference guide with screenshots (3–5 pages)
• New Student Data Checklist (1 page)
• Email template content guide with personalization field reference (2 pages)
• Escalation contact card: MSP support email, phone, and expected response SLA
• Data Processing Agreement copies for client records
• Compliance checklist: FERPA, COPPA, CAN-SPAM, TCPA requirements and how the system addresses each

Maintenance

Ongoing MSP Maintenance Responsibilities:

Daily (Automated)

• Make.com scenario runs automatically at 07:00 AM client time. MSP receives email alert ONLY if the scenario fails. No daily manual action required.

Weekly

• Review the Monday summary report email for anomalies: sudden drops in renewal rate, unexpected zero-deal counts, or error patterns.
• Check Make.com execution logs for warnings or partial failures (15 minutes).
• Verify SendGrid email deliverability metrics: bounce rate should stay below 2%, spam complaints below 0.1%.

Monthly

• Audit Make.com operations usage vs. plan limit (10,000 ops/month on Core). If consistently above 8,000, recommend upgrade to Pro.
• Review Twilio SMS delivery rates and costs. Flag any numbers that consistently fail delivery.
• Verify all API connections are healthy (Teachworks, SendGrid, Twilio, Stripe, HubSpot) — Make.com will auto-alert on failures, but proactive checking catches token expirations before they cause outages.
• Export and archive Make.com execution logs for FERPA compliance documentation.
• Invoice the client for monthly managed services.

Quarterly

• Review renewal rate trends with the client. If renewal rates plateau or decline, recommend A/B testing email subject lines or adjusting reminder timing.
• Verify DPAs with all vendors are still current and haven't been superseded by policy changes.
• Check for vendor pricing changes or plan modifications that affect the client's costs.
• Review and update email template content if the client has changed pricing, subscription terms, or branding.
• Verify COPPA/FERPA compliance posture — especially if the client has started serving a younger age group.

Annually

• Comprehensive system review: test all workflow routes end-to-end with synthetic data.
• Renegotiate software subscriptions for best pricing.
• Review and refresh the client's parent communication consent documentation.
• Update DNS records if the client changes email domains.
• Propose workflow enhancements: win-back campaigns for lapsed students, referral incentives for renewed students, or integration with new platforms the client has adopted.

SLA Considerations

• Target uptime: 99.5% (aligned with Make.com's SLA).
• Response time for critical failures (scenario not running): 4 business hours.
• Response time for non-critical issues (template change request, report question): 1 business day.
• Escalation path: Client admin → MSP help desk → Assigned MSP technician → MSP account manager.
• If a vendor API changes or breaks (e.g., Teachworks updates their API): MSP commits to remediation within 48 hours of discovery.

Alternatives

Zapier Professional (Simpler, Higher Cost)

Replace Make.com with Zapier Professional as the workflow automation engine. Zapier offers a more intuitive interface with a massive library of 7,000+ pre-built app connections. The workflow would use Zapier's multi-step Zaps with Paths (conditional branching) instead of Make.com's visual scenario builder. Setup is approximately 30% faster due to Zapier's guided connection flow and pre-built Teachworks/SendGrid/Twilio/Stripe/HubSpot integrations.

Microsoft Power Automate (For M365-Heavy Clients)

Replace Make.com with Microsoft Power Automate, leveraging the client's existing Microsoft 365 subscription. Many education organizations already have M365 A3 Education licenses which include Power Automate with standard connectors. The workflow would use Power Automate's scheduled cloud flows with condition actions and the HTTP connector for Teachworks API calls. CRM functionality could shift to Microsoft Dynamics 365 or a SharePoint list instead of HubSpot.

n8n Self-Hosted (Maximum Control, White-Label)

Replace Make.com with n8n Community Edition self-hosted on the Dell OptiPlex 7020 Micro at the client's location. n8n is an open-source workflow automation tool that provides full data sovereignty — no student data leaves the client's premises (except for outbound API calls to SendGrid, Twilio, and Stripe). The MSP can white-label the n8n interface behind their own branding. There are no per-execution fees regardless of volume.

TutorCruncher + Built-in Automation (Simplified Stack)

Replace Teachworks with TutorCruncher, which has a more comprehensive REST API with native webhooks, and leverage TutorCruncher's built-in email notification features for basic renewal reminders. This reduces the number of external services needed — TutorCruncher can handle basic email reminders natively, and the workflow engine is only needed for SMS, Stripe billing, and CRM updates.

ActiveCampaign as Combined CRM + Email Engine

Replace both HubSpot CRM and SendGrid with ActiveCampaign, which combines CRM pipeline management and email marketing automation in a single platform. ActiveCampaign's automation builder can handle the multi-step reminder sequences natively (30/14/7/0-day), reducing the workload on the Make.com workflow engine. Make.com would only need to handle the Teachworks data pull and Stripe billing; ActiveCampaign handles all communication logic and CRM tracking.