Fixed Route Anti-Cannibalization (FRAC) helps your agency prioritize fixed-route services by automatically hiding on-demand trip options from riders when a suitable fixed-route alternative exists. This reduces unnecessary demand on your microtransit or paratransit services, lowers operating costs, and encourages ridership on your fixed-route network.
How it works
When a rider searches for a trip, Spare's trip planner finds both on-demand options and fixed-route journey options. FRAC compares these results against the conditions you've defined. If at least one fixed-route option meets all of your conditions, the direct on-demand option is hidden from the rider.
FRAC evaluates whether to filter on a per-service basis. You create a set of rules (called a "profile") and assign that profile to one or more on-demand services. Only those assigned services will have their on-demand options filtered.
Setting up FRAC
Prerequisites:
Your organization must have multimodal trip planning enabled with at least one GTFS feed configured.
The FRAC feature must be enabled for your organization. Speak with your Spare Representative to get this turned on.
Riders must be on Spare Rider App version 4.4.8 or later for FRAC to take effect in the app.
Steps:
Navigate to Multimodal Settings in Spare Operations.
Under "Hide on-demand options from riders when there are preferable fixed route options", add a new profile. Creating a new profile automatically enables FRAC — there is no separate checkbox to turn it on.
Define your conditions (see below).
Assign the profile to one or more on-demand services.
Press Save.
Configurable conditions
You can enable any combination of the following conditions. A fixed-route option must meet all checked conditions to be considered "preferable" and hide the on-demand alternative:
Maximum number of transfers — The fixed-route trip must have no more than this many transfers. For example, setting this to 0 means the rider will only be nudged toward direct fixed-route trips with no transfers.
Maximum total walking duration — The total walking time across all legs of the fixed-route trip must be less than this value (in minutes).
Maximum trip duration (as a percentage) — The fixed-route trip duration must be less than this percentage of the best on-demand option's duration. For example, 100% means the fixed-route trip must be the same duration or shorter; 150% means up to 1.5x longer is acceptable. If an on-demand trip has a window for a duration (5-15 mins) then the midpoint will be used to compare (10 mins).
Departure delay (Leave-At trips) — If the rider books a "Leave At" trip, the fixed-route option must depart within this many minutes after the requested departure time.
Arrival delay (Arrive-By trips) — If the rider books an "Arrive By" trip, the fixed-route option must arrive within this many minutes before the requested arrival time.
Testing FRAC in the Multimodal Settings page
The Multimodal Settings page includes a built-in testing tool. You can use this tool to enter an origin, destination, and time to see how the system would respond to your FRAC rules.
You do not need to save your FRAC profile before testing. If you test without saving, the test will use your current draft settings but will not affect the experience for real riders. This is useful for experimenting with different rule combinations before committing them. Once you save the profile, the new FRAC settings will take effect for riders.
The test results will show you which trip options would be shown to riders and which would be hidden based on your rules. There are a few important things to know about testing in admin:
On-demand services need available capacity. For on-demand results to appear in the test, the service must have a scheduled duty on the correct fleet that is either currently on time or scheduled in the future — and that duty must have available capacity on the vehicle. The test page does not rely on unmatched requests.
The test does not pass a rider ID. This means any service that restricts access to a specific group, or services that use an Open Fleet requiring a rider agreement, will not return results in the test tool.
Testing FRAC in the Rider App
To see FRAC in action from the rider's perspective:
Ensure you are on Rider App version 4.4.8 or later. You can check your version from the Account menu at the bottom of the screen.
After making changes to your FRAC rules in admin, force close the rider app and reopen it. Changes will not reflect until the app is restarted.
Search for a trip using an origin and destination where you expect both a fixed-route and on-demand option to exist.
If the fixed-route option meets all your FRAC conditions, you should see only the fixed-route trip — the direct on-demand option should be hidden.
Troubleshooting
If FRAC does not seem to be working as expected, check the following:
Rider app version: Confirm you are on version 4.4.8 or later. Earlier versions do not support FRAC filtering.
Force close the app: After updating FRAC settings in admin, the rider app must be force closed and reopened for changes to take effect.
Duty and capacity: The on-demand service must have an active duty with available vehicle capacity for the requested time. If there's no duty scheduled, no on-demand option will appear regardless of FRAC settings — which can make it hard to tell if FRAC is working.
Profile assignment: Ensure the FRAC profile has been assigned to the correct on-demand service and that you've pressed Save.
Open Fleets and group-restricted services: Services using an Open Fleet that requires a rider agreement, or services restricted to a specific rider group, will not appear in the admin test tool because no rider ID is passed during testing. These services will still work correctly for real riders in the app.
Example configurations
Here are some real-world examples of FRAC settings that agencies have used:
Don't remove demand response options often: 0 transfers, 10 min walking, 100% duration, 15 min departure delay, 15 min arrival delay. This will hide on-demand options whenever there is a direct, comparable-duration fixed-route trip nearby.
Remove demand responses sometimes: 1 transfer, 15 min walking, 150% duration, 20 min departure delay, 20 min arrival delay. This allows for one transfer and gives more flexibility on duration, so riders are only nudged toward fixed route when it's a clearly reasonable alternative.
Remove demand responses most of the time: 5 transfers, 60 min walking, 60 min wait. These permissive settings will filter out nearly all on-demand options and can be useful for verifying that FRAC is functioning correctly before fine-tuning.
Frequently asked questions
Does FRAC work with GTFS Realtime?
FRAC works with both GTFS Schedule (static) and GTFS Realtime data. If your organization has GTFS-RT configured, FRAC will use real-time arrival information when the trip is close enough in time.
Is FRAC configured per-service or per-organization?
FRAC profiles are assigned to individual on-demand services. This means you can apply different FRAC rules to different services within the same organization, or choose not to apply FRAC to certain services at all.
Does FRAC filter out multimodal trips that include an on-demand leg?
No. FRAC only filters out the direct on-demand option (the standalone microtransit trip). Multimodal journey options that combine fixed-route legs with on-demand legs are not affected.
Will riders be told why the on-demand option isn't available?
Currently, riders are not shown a message explaining that an on-demand option was hidden due to a fixed-route alternative. The on-demand option simply does not appear. Customized messaging is on our roadmap.
For more information or to get FRAC enabled for your organization, please reach out to your Spare Representative.