Custom Billing Cycles

Rotor Team,

I wanted to share structured feedback based on actively trying to build my real client base and service agreements inside Rotor. I like the direction of the platform and I can see the potential, but as I’ve begun entering actual customer arrangements, I’m running into a few workflow gaps that make it difficult to represent how my business truly operates.

I run a recurring service business with a mix of commercial storefronts, offices, banks, specialty properties, and some residential/lodge-type work. My business is not built on a single recurring template. It relies on a combination of fixed schedules, alternating service patterns, client-specific agreements, and billing cycles that often do not match individual visit dates. Because of that, I need Rotor to support more than simple recurring jobs with one static fee and one static invoice cadence.

I wanted to outline my operating model clearly, then explain what is currently missing and what would make Rotor much more usable for businesses like mine.

1. How my business actually operates

My clients do not all fall into one structure. I have several different types of agreements running at the same time.

A. Different billing cadences across the client base
Some clients are billed monthly.
Some are billed quarterly.
Some are billed at time of service.
Some are as-needed / one-off.

In my own internal system, I effectively track these as:

• Monthly invoice

• Quarterly invoice

• Bill at time of service

• As-needed / one-off

That means the platform needs flexible billing logic at the client or agreement level, not just the job level.

B. Service cadence and billing cadence are often different
A major pattern in my business is that the service frequency does not always match the billing frequency.

Examples:

• A client may be serviced twice monthly but still billed monthly

• A client may be serviced monthly but billed quarterly

• A client may be serviced twice monthly with one service including interior work and the other not

• A client may have a recurring exterior service but separate quarterly or periodic interior service logic

This is one of the biggest mismatches I’m seeing right now. Rotor seems to lean toward a simpler one-job / one-schedule / one-billing structure, while my actual accounts often require multiple service events to roll up into a single monthly or quarterly invoice.

C. Many agreements have patterned or alternating service logic
Some accounts follow a repeated pattern rather than a fixed identical recurrence.

Examples from my business:

• Some clients are bi-weekly, but every other visit includes interior service, which materially changes the scope and fee

• Northern Minnesota Eye Care is a good example of this kind of pattern: it is serviced twice monthly, but the interior occurs every other service rather than simply being a fixed quarterly add-on

• Some accounts have regular exterior maintenance but a heavier interior service on a certain cadence

• Some monthly accounts have a quarterly interior component layered on top of the regular service schedule

That means I need the system to support patterned recurrence, not just “repeat the same thing every X days/weeks.”

D. Some accounts are bundled for billing
Certain locations are part of a larger grouped billing arrangement rather than each site being invoiced entirely separately.

Example:

• Some Pack & Mail locations are serviced individually but bundled into a quarterly billing structure rather than treated as isolated monthly invoices

So ideally Rotor should be able to support either:

• grouped invoicing across multiple locations under one client/account, or

• line-item rollups from multiple jobs into one invoice

E. There are client-specific rules and exceptions
My agreements also include special rules that matter operationally.

Examples:

• Some invoices are delivered on a specific service visit, not just generated automatically whenever a job occurs

• Some clients missed visits due to weather, but billing and service cadence still need to be reconciled properly

• Some clients have separate seasonal or special services that replace or override a standard visit

• Some clients have unique service notes that affect whether interior is done, when it is done, and how it is billed

In other words, a lot of my business depends on agreement logic, not just calendar logic.

2. What I am currently running into in Rotor

A. No visible way to delete a job once created
This is one of the first issues I noticed. I can create jobs, but I’m not seeing a way to delete them.

That becomes a real problem when:

• I create a test job

• I enter something incorrectly

• I want to restructure an agreement

• I need to clean up bad or duplicate data during setup

At minimum, I need:

• Delete job

• Archive job

• Cancel job

• Undo or reset mistaken setup entries

Without that, I can’t safely build and refine the system.

B. No clear support for alternating service structures
I have clients where Visit A and Visit B are not the same.

Example:

• Visit 1: exterior only

• Visit 2: exterior + interior

• Then the cycle repeats

That means:

• the scope is different

• the price is different

• the work order is different

• the invoice rollup is different

Right now I’m not seeing a clean way to represent this in Rotor.

What I would need is something like:

• alternating visit templates

• recurring sequence logic

• service pattern builder

• “every other visit includes X”

• multiple repeating job types under one account

C. No clear quarterly invoicing option
A large portion of my client base is billed quarterly, and I’m not seeing an option that fits that.

This is a major gap for my business, because I may perform multiple services over a quarter and then bill them together. In other cases, I may have monthly service activity but quarterly invoicing. Rotor needs to let billing cadence be independent from service recurrence.

What I would need:

• quarterly invoicing as a first-class billing option

• invoice aggregation by quarter

• the ability to choose invoice cadence separately from service cadence

• the ability to generate one invoice from multiple completed jobs/services over a defined period

D. Difficulty representing highly customized client agreements
A number of my clients do not fit a normal template. They have combinations like:

• twice monthly exterior

• quarterly interior

• every-other-service interior

• grouped locations under one invoice

• monthly service but quarterly billing

• time-of-service billing on some accounts

• unique notes affecting when invoices are physically handed over

That means a simple recurring job setup is not enough. I really need a client agreement layer that can store:

• service frequency

• scope variations

• billing cadence

• invoice grouping rules

• service notes

• exceptions / overrides

3. What I believe Rotor needs in order to support businesses like mine

A. Job lifecycle controls
Please add:

• delete job

• archive job

• cancel/deactivate recurring job

• duplicate/edit recurring template safely

• change history or versioning if possible

B. Agreement-level service logic
Please add the ability to define a service agreement that sits above individual jobs.

That agreement should ideally allow:

• service frequency

• billing frequency

• pricing rules

• alternating or rotating service patterns

• service notes

• seasonal exceptions

• grouped locations / bundled invoicing logic

C. Pattern-based recurring scheduling
Please consider adding support for recurring sequences such as:

• every other visit includes interior

• 1st service of month differs from 2nd service of month

• monthly recurring service with quarter-month add-ons

• rotating service templates tied to a cycle rather than a single repeated task

D. Separate billing cadence from service cadence
This is probably the single biggest need.

I need to be able to say:

• service this client twice monthly

• but bill monthly

or:

• service monthly twice exterior, interior quarterly

• but bill quarterly

or:

• complete multiple jobs

• then roll them into one invoice

Billing should not be locked to the current structures.

E. Aggregated invoicing
Please add the ability to:

• aggregate completed services into one invoice by month or quarter

• group multiple jobs/visits under one billing period

• group multiple locations under one client invoice when applicable

• preview what will be included before generating the invoice

F. Custom notes / operational exceptions
I also need a place for agreement-level instructions like:

• interior every other service

• invoice delivered on second service of month

• winter weather affects cadence

• special service replaces standard monthly visit when scheduled

Those notes are essential to running the account correctly.

4. Why this matters beyond my business

I don’t think these needs are unique to me in a narrow sense. I think Rotor has a real opportunity here.

A lot of real-world service businesses operate like this:

• recurring, but not identical every visit

• custom agreements by client

• invoicing by period instead of by job

• mixed service types under one account

• exceptions, overrides, and seasonal patterns

If Rotor can support that, it becomes much more powerful for service businesses that are beyond the simplest lawn-care-style template.

Right now, the platform feels closest to supporting a straightforward recurring job model. My business, and I suspect many others, requires a contract-and-workflow model with more nuance.

5. My request

I’d love for the team to review these workflow gaps and consider them as part of Rotor’s product development roadmap.

The biggest immediate needs from my side are:

1. Job deletion / archive / cleanup controls

2. Quarterly invoicing

3. Billing cadence separate from service cadence

4. Alternating / patterned recurring service logic

5. Support for custom client agreements

6. Aggregated invoicing across multiple visits and, where needed, multiple locations

7. Closing

I’m sharing this in a collaborative spirit because I do see real potential in Rotor. I want to keep building inside it, but I need to know the system can eventually support the way my business actually runs in practice.

I’d be very happy to provide additional examples, screenshots, or specific client scenarios if that would help. I’m also happy to walk through a few real agreements step by step if that makes it easier for the team to see how these structures work operationally.

I’m committed to helping shape Rotor into a tool that fits real-world service businesses like mine, and I appreciate the work that’s already gone into it.

Thank you,
Alex