Why us Easy integration
Developers
Talk to sales
Industries · Telecom

Built around the billing cycle

A subscriber pays you every month for two years and thinks about you twice: when they sign up, and when the contract ends. We turn top-ups and bill payments into a run for paying on time and a monthly mission, so something happens in the twenty-two months in between.

The shape of a contract

A subscriber is active for two months, then silent for twenty

There is an onboarding month, then a long plateau where the only event is money leaving an account by direct debit, then a short window where they decide whether to stay. Everyone builds for the first and last. The plateau is where the decision is actually made.

The cycle is not the calendar

Month is the natural recurrence, but a subscriber billed on the 19th is not on a calendar month. Enrol them when their cycle opens.

Tenure grows while nothing happens

Two years of loyalty can pass with no voluntary interaction. The useful rules look back over long windows, such as bill_paid over all time.

one postpaid subscriber · twenty-four months
Twenty-four months of one subscriber. Twenty-four bars, one per month of a two-year contract. The first month is tall because of onboarding. Months two and three fall away. The long middle is a flat, low plateau of one bill payment each. The last three months rise steeply as the contract end approaches. A band over those last three months marks the window in which they decide whether to stay. times they chose to interact they decide here m1 m6 m12 m18 m24 Two busy months, then a long plateau of one payment each.

Reading the chart: each bar is one month of a two-year contract, counting only voluntary interactions. Month one is tall because of onboarding. Then a long flat plateau where the only event is a direct debit. The last three months climb as the contract end comes into view, and the band marks them.

The rule you would build

Paying the bill on time each month builds a run

A streak counts consecutive days, so a monthly habit has to live inside the condition rather than in the counting. Ask whether a bill was settled in a window wide enough to cover the gap between bills, and one payment keeps every day in that month qualifying.

how this is set up
Match all of the 2 rules below
Count of bill paid where days late 0 rolling 35 days
Attribute account state = active
Then: day counted · milestones at 90, 180, 365, 730 days
rolling 35-day condition · three billing cycles
Three billing cycles and one late payment. A ninety-five day timeline covering three billing cycles. A bill settled on day three keeps the rolling thirty-five day condition satisfied through day thirty-eight; a second bill on day thirty-three extends it to day sixty-eight, so the run advances continuously across the first two cycles. The third bill arrives late, on day seventy-two, leaving four days in which the window is empty and the run resets to one. A new run then begins and continues to day ninety-five. bill settled condition holds, the day counts window empty, the run restarts run advances every day · days 1 – 65 new run, counting from 1 bill paid cycle 1 · on time bill paid cycle 2 · on time bill paid cycle 3 · four days late day 1 day 35 day 70 day 95 the longest run ever reached is kept permanently, even after the reset

Reading the diagram: a bill settled on day three keeps the condition true for the next thirty-five days, and a second bill on day thirty-three extends it again, so the run carries straight across both cycles. The third bill arrives late, leaving four days with nothing in the window, and the run resets to 1 before starting again.

KeyKindWhat it carries
bill paid Metric · Currency An invoice settled. Send it when the collection succeeds.
topup Metric · Currency Credit added to a prepaid line.
days late Property · Number How late the payment was. Zero means on time.
line type Property · String Prepaid or postpaid.
account state Attribute · String Active, suspended, in collections. Read by eligibility rules.

Send us one bill event

Send us the event your billing system sends when a payment succeeds. We will build the on-time payment run in a test account while you watch.