AlterCall / Client lifecycle / System 02 of 06
2021Recorded work
Subscription reporting and payment follow-up
Keep subscription and payment information current, and show customer success which accounts need a payment follow-up.
- Noah’s contribution
- Noah developed the synchronization logic, investigated status mapping and documented the reporting rules.
- Historical stage
- Configured integration and tests, with successive review versions
- Part of the business
- AlterCall overview ↗
- Stripe
- Monday.com
- Make / Integromat
- Slack
Inside this system
The workflow
The handoffs
inside the work.
Follow the main path and its branches. Select a step for context; the account below explains what was built, tested or planned.
- Subscription event
A Stripe subscription-related event starts the event-driven reporting path. - Daily billing-period check
Find Monday records whose reporting period ended yesterday, then refresh their Stripe data. - Retrieve the related Stripe records
Subscription, customer, invoice and plan data each supply part of the report. - Map separate status columns
Explicit indexes map subscription status, payment status and plan independently. - Does the Monday item exist?
The event route searches before writing; the daily route already starts from an item. - Create a reporting item
Add the missing subscription record with its mapped context and billing period. - Update an existing item
Refresh the period dates and current states on the matching reporting record. - Monday subscription report
Shared records retain billing periods, plan, subscription state and payment state. - Unpaid or past due?
Inspect updated payment state to decide whether customer-success follow-up is needed. - Notify customer success
Existing-record updates can lead to unpaid or past-due follow-up. The daily path has a configured 9 AM schedule; this does not set the timing of every subscription-event alert.
Key records
The information
that carries forward.
| Record | Information | Purpose |
|---|---|---|
| Subscription | Customer reference, plan, subscription state and period dates | Represent the ongoing billing arrangement. |
| Payment state | Invoice/payment status, separately mapped from subscription status | Identify a collection follow-up without conflating it with membership state. |
| Customer-success alert | Customer context and unpaid/past-due state | Give the team a specific item to review. |
Inside the system / 01
An event stream is only part of the report
AlterCall needed a subscription view that stayed useful as customers paid, changed plans and entered a new billing period. One path updated it when a subscription changed; a daily check refreshed records whose billing period had just ended.
The event path retrieved the related Stripe customer, subscription, invoice and plan records. It then found the reporting item and either updated it or created the missing record.
Inside the system / 02
Keep payment and subscription state separate
The early version combined active status and paid status into one interpretation. Subsequent recordings explicitly separated subscription status from payment status. That made it possible to express an ongoing subscription and an unpaid invoice without forcing both ideas into a single label.
A status-mapping defect could put the wrong label on a Monday record. Noah used explicit status indexes for subscription, payment and plan fields to make the intended choices unambiguous in the recorded integration.
Inside the system / 03
Refresh the period even when no useful event arrives
The daily path looked for a period end date of yesterday, retrieved fresh Stripe information and updated the billing-period dates. Reviewed versions scheduled that work at 9 AM so customer-success notifications arrived during a practical working period. Because this path began with an existing reporting item, its remaining write operation was an update.
The development history included proposed grace-period checks with different thresholds. Later reviews described the daily period refresh and unpaid/past-due alerts. Those versions are kept distinct; a seven-day or fifteen-day experiment is not presented as the final universal collection policy.
Inside the system / 04
Make business definitions part of the integration
The recordings exposed a separate policy question: a cancelled Stripe subscription did not necessarily mean the same thing as a cancelled customer relationship. Stopping automatic rebilling, pausing participation and ending participation could require different business handling. Noah raised those distinctions with the team instead of silently treating them as equivalent.
The configured integration combined subscription updates, daily reconciliation and customer-success alerts. The team still needed to settle some billing definitions; full activation and improved collections were not established.
Within AlterCall