RIVETAI · PRODUCT AND RETENTION
Actor Availability for Scheduling Feasibility
Turning an AI-generated schedule into something a production team could actually use.
RivetAI could generate a production schedule, but users regularly dropped out at the point of determining whether the cast could actually work on the proposed dates.
I made actor availability part of the scheduling engine itself. Users could enter cast constraints, generate more feasible scenarios, edit schedules with conflict feedback, and keep stress-testing the plan inside RivetAI.
~25%
reduction in user churn
Approximate product metric supplied by Priya. Actor availability was a significant contributor to improved retention, though the result was not measured through a controlled causal experiment.
Role
Product Manager · Acting Product Lead
Focus
Product discovery, scheduling logic, retention
Outcome
Approximately 25% reduction in churn
Problem
Users could generate schedules but could not reliably test them against the availability of the actors required to execute them.
Evidence
Users directly expressed frustration, and product analytics showed recurring abandonment at the point where schedules had to be reconciled with cast availability.
Product decision
Make actor availability an input to the scheduling engine, not passive information stored beside the schedule.
Result
Users could complete more of the scheduling workflow inside RivetAI, repeatedly test feasibility, and identify conflicts before committing to changes.
A schedule could be logically correct and still be impossible to shoot.
RivetAI generated production schedules, but real productions are constrained by people. Users still had to leave the product to determine whether principal actors, supporting cast, and extras could work on the dates the schedule required.
Some users described this directly as frustrating. Product analytics told the same story: a recurring drop-off where users needed to reconcile the proposed schedule with actual cast availability.
This wasn't a minor missing input. It was a structural break in the end-to-end workflow, and a likely contributor to churn.
The missing capability wasn't a calendar. It was a feasibility engine.
Users entered availability through a calendar, selecting the dates each actor could work. Those dates became inputs to RivetAI's scheduling engine, which generated or reorganized shooting scenarios around the cast's real constraints.
The logic distinguished between cast priorities. Principal actors, who usually carried the strictest and most consequential constraints, received the highest priority. Supporting or not-yet-finalized actors received lower priority; extras were treated as zero-priority.
The schedule then surfaced relevant availability flags. When a user edited it, the product could indicate whether the change stayed feasible or introduced a conflict.
Calendar-to-schedule workflow
01
Enter availability
Select available dates for each actor
02
Assign cast priority
Principal, supporting/TBD, and extra cast receive different priority levels
03
Generate scenarios
The scheduling engine organizes shoot plans around cast availability
04
Review flags
The schedule surfaces relevant availability constraints
05
Edit and test
Proposed changes are checked against actor conflicts
06
Repeat
Teams keep stress-testing the schedule as production conditions change
loops back to enter availability
Principal actors: Highest priority
Supporting or TBD actors: Lower priority
Extras: Zero priority
A generalized representation of the workflow and priority logic. It does not reproduce RivetAI's private interface or proprietary scheduling implementation.
Illustrative scheduling conflict
A principal actor is available only during a narrow set of dates. The initial schedule places several of that actor's scenes outside the available window.
RivetAI reorganizes the schedule around the principal actor first, then fits supporting cast and extras into the remaining plan. If a user later moves a scene to a conflicting date, the schedule flags it before the change makes the plan infeasible.
An explanatory scenario, not a quotation from a specific customer.
Automate the logic without hiding the consequences.
Availability had to affect the existing scheduling engine without making its decisions opaque. Users needed enough visible feedback to understand why a scenario worked, which constraint drove it, and when an edit introduced a conflict.
The scope stayed focused on schedule feasibility rather than expanding into a complete cast-management platform. Contracts, agency coordination, talent communication, and call-sheet distribution stayed outside the feature.
That tradeoff kept the team centered on the core problem: producing a shooting schedule that could actually be executed.
Before
- 01Generate an initial scheduleworkflow breaks here
- 02Leave RivetAI
- 03Reconcile actor dates elsewhere
- 04Manually identify conflicts
- 05Return to revise or abandon the workflow
After
- 01Enter actor availability
- 02Generate scenarios around cast priority
- 03Review availability flags
- 04Edit and identify conflicts
- 05Continue stress-testing inside RivetAI
A more complete workflow gave users a reason to stay.
After actor availability shipped, users could remain inside RivetAI for more of the scheduling process: entering cast constraints, generating workable scenarios, revising the plan, and testing new combinations without reconciling availability in a separate tool.
This more complete workflow contributed to an approximately 25% reduction in user churn.
Actor availability also made RivetAI more credible for enterprise use. On larger productions, actor constraints are often among the most consequential inputs in the schedule, and the rest of the plan may need to organize itself around them.
What I would measure next
- How often users revised schedules after entering availability
- Where actor conflicts appeared most frequently
- How many schedule alternatives users tested
- Whether the feature shortened the path to a workable production plan
Confidentiality note
This case study focuses on my role, decisions, and product process. Certain interface details, customer information, and business metrics have been omitted or generalized to respect company confidentiality.