Use case: During the promo code rule creation, be able to copy a rule to edit and iterate on the existing ones created. Use the "copy" icon in the promo rule view to create a duplicate to edit.
\

Use case: Create different time based intervals of fees. Ex: Cancellation fee is 50% from 0 - 24 hours prior to departure, then 24 - 48 hours is 25%, and 0% fee greater than 48 hours.

Configuration: Administration -> Fees -> Create or select a fee -> Configure fee rule: Apply on cancel (per ticket), and set the "+ Add new time based rule"

For more details please see our dedicated Support Article: Fees](https://support.betterez.com/content/admin/500_fees_create#fees-create).

Use case: Operators who need to sell in person, can now do so integrated with Betterez. The purchase price is sent directly from Betterez to the device, for a seamless sales process. Purchase confirmation from Stripe completes the payment. Internet is required to communicate between the Stripe Device and Betterez.

Configuration: "Enable Administration / Payment -> stripe_terminal prior to attempting to pair the device in Betterez Administration / Payment Terminals / Stripe Follow the steps below:

1. https://support.betterez.com/content/admin/267_payments_stripe_terminal
2. https://support.betterez.com/content/admin/270_payment-terminals#stripe-terminals---create-location-using-stripe-dashboard
3. https://support.betterez.com/content/sales/903_payments_stripe_terminal

Use case: This feature provides drivers with the ability to complete trips independently, improving operational control and ensuring accurate trip closure. It eliminates the need for back-office intervention while ensuring that tracking stops once the trip has ended, reducing unnecessary background activity and improving system performance.

Configuration: Administration > Mobile Apps > Download the APK or through Apple Store

For more details please see our dedicated Support Article: Scanner App.

Use case: Keeps percentage-based fees within a defined range, ensuring fair, predictable, and transparent charges

Examples: Cancel Fee: 15%, Min $5, Max $25 → $200 cancellation = $25 (capped). Change Fee: 10%, Min $10, Max $30 → ensures consistent fees across tickets.

Configuration: Administration → Fees and Rules → Change/Cancel Fee Settings Users can now set both Minimum Amount and Maximum Amount when defining fee rules.

For more details please see our dedicated Support Article: Fees Create.

Use case: This helps teams instantly identify underperforming trips, improve load management, and keep FOF data consistent across both reports.
Configuration: Administration > Sales & Inventory > Operation Settings Here, you can set your FOF goal — any value between 0% and 100% — to define the minimum seat occupancy you want to achieve.
Criteria:

• Trips below the goal appear in red.
• Trips meeting or above the goal look normal.
• If no goal is set, all trips are shown as meeting it.
  
  For more details please see our dedicated Support Article: 5-DO.

Use case: Gives operators a quick, complete view of trip performance — how full each bus was, how much revenue it made, and which trips need attention — making decision-making faster and easier.
Criteria: Shows route info, travel date and time, seat and standing capacity, trip status, tickets sold, total revenue, occupancy rates, distance traveled, and trip completion.

For more details please see our dedicated Support Article: Reports.

Use case: Helps operators easily evaluate trip efficiency, identify high and low performers, and make data-driven planning decisions.
Criteria: Displays total trips, tickets sold, seat capacity, available seats, total revenue, trip occupancy, and revenue performance — providing a clear overview of both operational and financial performance. \

• Seat-kilometers offered = total seats on the bus × trip distance

  How much travel space was available.

• Seat-kilometers used = number of passengers × distance they traveled

  How much travel space was actually used.

• Occupancy % (FOF) = (used ÷ offered) × 100

  Shows how full the bus was.

• Revenue performance (FO) = (actual revenue ÷ ideal revenue) × 100

  Shows how much money was made compared to what could’ve been made if every seat sold.
  Example: If a bus has 20 seats and travels 50 km, that’s 1,000 seat-kilometers offered. If 15 passengers ride the whole way, that’s 750 seat-kilometers used. Occupancy = (750 ÷ 1,000) × 100 = 75% full.
  
  For more details please see our dedicated Support Article: Manifests.

Use case: Let users quickly create a copy of an existing manifest without re-entering all the details, saving time and reducing setup errors.
Criteria: : Clicking Duplicate takes you directly to the Duplicate Manifest page, where you can review and confirm the copied trip details.

For more details please see our dedicated Support Article: Manifest.

Use case: Ensures all stations are properly categorized, improving data accuracy and consistency across configurations and reports.

For more details please see our dedicated Support Article: Manifest.

Use case: Ensures all stations are properly categorized, improving data accuracy and consistency across configurations and reports.

For more details please see our dedicated Support Article: Manifest.

Use case: Makes it faster to find specific trips and analyze results. The filtered data can also be exported directly to Excel for reporting or review.
Criteria:

• “Departure” filter renamed to “Origin” for consistency.
• Time filters split into Departure Time and Arrival Time.
• Results table now includes columns matching all new filters.
• Added Download button to export all results (no pagination).
  
  For more details please see our dedicated Support Article: Manifest.

Use case: Gives drivers quick access to contact passengers when needed, improving communication and trip coordination.
Configuration:

• A new toggle in Administration ➝ Scanning controls whether phone numbers are visible.
• When enabled, the phone number appears in the ticket details (like in the 5-Day Outlook manifest).
• Drivers can copy the number by tapping it, or tap to call directly from the app (if supported).
• The feature is off by default for privacy and control.
  
  For more details please see our dedicated Support Article: Driver's App.

Use case: Simplifies the driver’s view by hiding trips that aren’t relevant, making it easier to focus on their own schedule.

For more details please see our dedicated Support Article: Driver's App.

Use case: Gives operators more control over pricing and travel rules, so Flexpasses can reflect differences in service quality or brand offerings.
Configuration:

• Each Flexpass can be tied to one Brand and one Service Class.
• Pricing and usage are calculated according to the selected Brand and Service Class.
• We can create multiple Flexpass products for different brand/service combinations.
• Flexpasses can also use station groups, letting passengers board or redeem at any station within the group.
• Keeps pricing consistent and flexible across brands while maintaining simple setup and use. Example: A Flexpass for Brand A - Executive Class might cost more than one for Brand B - Standard Class and only work for those specific trips.
  
  For more details please see our dedicated Support Article: Flexpass.

Use case: Gives operators flexibility to offer different prices, validity periods, and travel networks for the same Flexpass product.
Configuration:

• In the pricing section, select Network Wide and add multiple options using “+”.
• Define uses, days to expire, and price (average price is auto-calculated).
• Customers choose from these options during purchase.
• Define which O&Ds are included or excluded from the pass (only one mode can be active).
• Redemption and results filter automatically by the Flexpass’s brand and service class.
• You can copy a Flexpass to create quick variants.
  
  For more details please see our dedicated Support Article: Driver's App.

Use case: Keeps passengers informed about schedule changes, improving communication and reducing confusion.
Configuration:

• Adds a new “Send Email” option next to the existing SMS option.
• Emails are sent only to passengers who have an email address on file.
• The button appears on the same screen where movements are confirmed.
  For more details please see our dedicated Support Article: Admin.

Use case: Automates the blocking process so operators can control availability without manual updates, preventing sales for certain routes or periods.
Configuration

• Blocks can be set for a specific time range and will auto-release once the period expires.
• Applies to the selected O&D and all intermediate stations.
  Example: Block sales from Córdoba to Realicó, including all stops in between.
  
  For more details please see our dedicated Support Article: Shift.

Use case: Lets operators plan and schedule price adjustments in advance, keeping pricing accurate and consistent over time.
Configuration

• Users can define start and end dates (with hour, minute, and second precision) for each price.
• The system will validate overlapping dates to prevent conflicts.
• Prices are based on the sale date and use the origin station’s timezone.
• Only active date ranges are shown; inactive ones are hidden or grouped separately.
• If a price isn’t valid for the sale date, the item cannot be sold
  
  For more details please see our dedicated Support Article: Shift.

Use case: Makes it easier for customers to receive their tickets directly on their phone after purchase.
Configuration:

• SMS is sent via Salesforce integration.
• The phone number must be entered twice manually (copy-paste disabled).
• The Send button stays disabled until both entries match.
• Once confirmed, the system sends the ticket(s) via SMS.
  
  For more details please see our dedicated Support Article: Admin.

Use case: Ensures passengers quickly receive their modified tickets directly on their phones after a change.
Configuration:

• SMS is sent through Salesforce integration.
• The phone number must be entered twice manually (copy-paste disabled).
• The Send button remains disabled until both entries match.
• Once confirmed, the changed ticket(s) are sent via SMS.
  
  For more details please see our dedicated Support Article: Admin.

**Use case:**Use case:

• Promotions can be configured as: Cancelable, Changeable or both
• These settings are defined in the Promotion Configuration UI, not in the payment method.
• The parameters will be pre-selected by default but can be manually unchecked as needed.
• A “Global Override” button allows changes that apply to all fare classes tied to the promo code.
  Configuration:
• WHEN configuring a new promotion
• AND setting cancel/change restrictions
• THEN the system should allow enabling or disabling these parameters accordingly.
  
  For more details please see our dedicated Support Article: Promotions.

Use case: To incentivize group travel by offering discounts or special pricing when multiple passengers are booked together:

• Allow defining group-size-based promotions (e.g., “Family of 4” discount).
• Promotion activates only when the required number of passengers is included in a single purchase.
• Should integrate with existing promo rules (validity dates, routes, cancel/change settings, etc.).
• Display applicable group promotions automatically during the sales flow when conditions are met.
  Configuration:
• WHEN a booking includes the defined group size
• THEN the system applies the corresponding group promotion automatically.
  
  For more details please see our dedicated Support Article: Promotions.

Use case: Ensures passengers receive a valid transaction record and a ticket reflecting the average price per use, enabling official invoicing and accurate revenue recognition for the operating company.
Criteria:

• Upon redemption, a confirmation email is sent to the Flexpass holder.
• The generated ticket now displays the average price per use instead of $0.00.
• The average price is calculated as: Flexpass total price ÷ number of uses.
• Supports accurate tax reporting and OpCo revenue tracking.
  Note: This change does not affect existing Flexpass redemption logic — only the notification and pricing display behavior.
  
  For more details please see our dedicated Support Article: Flexpass.

Use case: Supports businesses managing multiple fare types or corporate accounts by ensuring payments are routed to the correct account for accurate reconciliation
Configuration:

• Set up under Admin > Payments > Pay on Account (Accounts Receivable) by associating fare types with Pay on Account registers
  Criteria:
• Automatically assigns the correct Pay on Account based on fare type.
• Restricted to tickets linked to the associated fare type.
• Not valid for paid-in items or SSRs.
• If no fare type is linked, Pay on Account continues to function as usual.
  
  For more details please see our dedicated Support Article: Payment Providers.

Use case: Ensures passengers receive a valid transaction record and a ticket reflecting the average price per use, enabling official invoicing and accurate revenue recognition for the operating company.
Criteria:

• Upon redemption, a confirmation email is sent to the Flexpass holder.
• The generated ticket now displays the average price per use instead of $0.00.
• The average price is calculated as: Flexpass total price ÷ number of uses.
• Supports accurate tax reporting and OpCo revenue tracking.
  Note: This change does not affect existing Flexpass redemption logic — only the notification and pricing display behavior.
  For more details please see our dedicated Support Article: Reports.

The report includes:

• Deposit date and time
• User’s shift location and shift ID
• Username and display name of the user who created the deposits
• User external ID
  
  Filters available: region, date & time range, shift location, and username. This report helps operators reconcile daily deposits and integrate seamlessly with external systems.
  
  For more details please see our dedicated Support Article: Reports.

Use case: In IMS, planning teams manage different types of itineraries. When a user needs to review the next 5 days, it is essential that they can quickly view only the trips that belong to the filtered label.
Configuration: Operations > 5 Day Outlook > Select the label filter

Without this filter, the user is overwhelmed by the amount of data and wastes time searching for relevant trips.

For more details please see our dedicated Support Article: Labels.

Use case: At IMS, planning teams manage different types of itineraries. When a user needs to tag a schedule with a particular label so that they can then filter it over the next 5 days, it is essential that they can quickly see only the trips that belong to the filtered label.
Configuration: Operations > 5 Day Outlook > Select the schedule and add the necessary label.
This feature allows you to view information labels more quickly in schedules and 5-day outlook.

For more details please see our dedicated Support Article: Schedules.

The expected behavior is for each currency to use its own fare tables to determine accurate pricing.
The current work focuses on handling the cancellation of Flexpass redemptions, as the multicurrency requirement may not be immediately necessary.

For more details please see our dedicated Support Article: Flexpass.

Key capabilities include:

• Apply rules based on the full journey (origin ➝ final destination), with support for connected trips.
• Flexible configuration options:

  Stations All stations
  All stations
  Specific station(s)
  Ability to tie to specific schedules.
  
  This feature allows operators to efficiently scale O&D restrictions across large station networks without managing route-by-route or schedule-by-schedule setups.
  
  For more details please see our dedicated Support Article: Paid In Item.

Use Case: Operators and drivers may need to view their upcoming or past trips in different orders depending on operational workflows. For example, viewing the most recent trips first can be useful during end-of-day reviews, while the default earliest-first helps with planning the upcoming schedule.

Configuration: No configuration required. Available by default in the latest version of the driver app.

Make sure to update to the latest driver app to see the latest features.

For more details please see our dedicated Support Article: Scanner App.

Two key updates have been made to the Pay Later configuration:

New Setting – Expiration Time Prior to Trip Departure
A new time-based parameter allows you to expire Pay Later reservations X minutes or hours before departure, whichever is earlier between this setting and the existing Maximum Waiting Time. This helps automatically free up held seats if payment is not initiated in time.

Updated Setting Language – Wait Time Departure Offset

New Name: Wait Time Departure Offset
New Tooltip: To permit payment processing to continue past the departure time of a trip, this setting allows the 'waiting for payment' status to extend beyond departure by the offset time specified.

These updates provide greater flexibility and automation in managing seat holds and payments near departure times.

Also updated:

• "Departure Offset" renamed to "Wait time departure offset"
• Tooltip updated for clarity.
  
  For more details please see our dedicated Support Article: Payment Providers.

Use Case: Bulk Move now supports seat reassignment based on leg-to-leg availability.
If two passengers are booked on the same seat but for non-overlapping segments (e.g., A > C and C > D on Seat 17), the system will now recognize that both can occupy the same seat without conflict. This enhancement ensures that fully booked trips can be moved efficiently without unnecessary seat rejections.

For more details please see our dedicated Support Article: Move.

Sales made through this option will be recorded under the offline agent’s shift, ensuring accurate reporting and capacity tracking, while the booking itself can be completed by an online manager or authorized user.

For more details please see our dedicated Support Article: Sell on Behalf.

Use Case: Displaying “Created by” and “Updated by” on the item details page When a user reviews entered payments, it is essential to know who added the original data and who modified it. This improves traceability, facilitates internal audits, and reduces disputes over the validity of the information. Without this visibility, the user must search external records or logs to identify the person responsible, which is time-consuming and increases the risk of error.

For more details please see our dedicated Support Article: Paid In Item.

Use Case:
Allows bulk move of tickets in "Waiting for Payment" status. Prevents the error: “Ticket cannot be moved because it has not been paid.” The ticket’s payment status stays unchanged and can still be completed later

Configuration:
Admin > Sales & Inventory > Operation Settings

For more details please see our dedicated Support Article: Move.

Key capabilities include:

• Manage and organize payment on account records in a CSV file.
  This feature allows you to download payment records to a CSV file and then view the information configured in each of them within the system.
  
  For more details please see our dedicated Support Article: Payment Providers.

This enhancement is managed by a feature flag and includes corresponding UI and API updates.
The system will either disable the Cancel button or display an error message when a cancellation is attempted for a redeemed Flexpass. All relevant product APIs have been updated to support reading and saving this new property.

For more details please see our dedicated Support Article: Flexpass.

Access via **Intelligence > Transactions.**
Apply filters, download CSV, and review all flexpass activity. Permissions must be enabled.

Use case: In passenger operations, canceling a manifest that already has passengers can lead to confusion, undue charges, or breach of contract. With the new rule, the system prevents this action from happening accidentally, ensuring that only empty manifests (without passengers) can be canceled.
Configuration: Administration -> Operations -> Inventory Settings → Checkbox “Prevent changing the status to Cancelled if there are passengers in the manifest” → Check the box to enable the restriction → Save settings

Checking the box prevents accidental cancellation of trips with passengers.

For more details please see our dedicated Support Article: Labels.

Use case: A user needs to send a ticket to an external printer. This feature allows them to:

• Download the attached PDF without relying on the system's default printer.
• Manually choose any printer connected to the device.
• This avoids confusion when the default printer is not suitable.
  Configuration: The feature is automatically enabled in the ticket view; the user will see a “Download PDF” button and, after opening it, will be able to use the standard print function of the browser/operator.
  
  For more details please see our dedicated Support Article: Printing.

Key capabilities include:\

• The ability to generate, view, and modify location closure records and their statuses directly from the back-office.
• New closure status options:

1. SENT: Default status when created by the agency.
2. CLOSED: Validated and confirmed as correct.
3. CLOSED WITH DIFFERENCE: Used when discrepancies exist between reported and deposited amounts.

• Users with appropriate permissions can approve, edit, or adjust closure details and deposits.
• When changing a status to “Closed with Difference,” users can leave a comment explaining the reason.
• In cases of shortfall, the difference is debited from the next closure; in cases of excess, it is credited to the next closure.
  
  This update adds visibility and control through the location closure summary, closure report, and location summary print template, ensuring accurate reconciliation across the network.

• Usage Deduction: Redeeming a round trip subtracts 2 uses from the flexpass.
• Validation: The system will prevent selecting a return trip if the flexpass has insufficient remaining uses.
• Implementation: Redemption occurs in a single flow, with safeguards to handle partial failures and ensure no uses are deducted if the process fails.
• Scope: Controlled via a feature flag for safe rollout.
  This improvement simplifies round-trip redemptions and ensures proper usage tracking for flexpasses.

Use Case: An operator sells a 10-use Flex Pass for 1,000 MXN.
Revenue is initially assigned to Operating Company A.

Over time:

• 5 uses are redeemed with services operated by Operating Company B → 5 uses × 100 MXN = 500 MXN goes to OpCo B.
• 3 uses are redeemed with services by Operating Company C → 3 uses × 100 MXN = 300 MXN goes to OpCo C.
• 2 uses remain unused upon expiry. The remaining 200 MXN can be allocated to OpCo A, B, or C, depending on policy.
  
  Operational Control Rules:
• The assigned OpCo is configured in Admin > Operating Companies.
• The assigned OpCo for the Flex Pass:
• Does not need to follow the usual Amenity Group / Brand restrictions, even when the system is configured to enforce OpCo/Amenity Group/Brand mapping.
• Acts as the initial revenue holder when the Flex Pass is sold.
• Revenue distribution occurs dynamically based on:
• The actual usage of the Flex Pass by the customer.
• Any unused uses remaining upon expiry.

• Purpose: Simplifies the sales process by pre-selecting commonly added items.
• Behavior: Passengers or agents can deselect the item if they do not wish to include it.
  This enhancement improves efficiency while maintaining flexibility for customer preferences.
  
  For more details please see our dedicated Support Article: Paid-In Items.

• Column Placement: Appears to the right of the existing “Shift Location” column.
• Filter Update: A new dropdown filter for Operating Company is now available, positioned below the “Manifest Date From/To” filters, defaulting to “All.
  This enhancement allows users to easily view and filter items by the assigned operating company.
  
  For more details please see our dedicated Support Article: Operating Companies.

• Purpose: Simplifies the sales process by pre-selecting commonly added items.
• Behavior: Passengers or agents can deselect the item if they do not wish to include it.
  This enhancement improves efficiency while maintaining flexibility for customer preferences.
  
  For more details please see our dedicated Support Article: Paid-In Items.

Use case: Back-Office Operator / Agency:
When a customer pays online or in person, the operator must decide whether to issue the ticket in digital (ENG) or physical (SPA) format. If the physical option is selected, tickets and complementary products are printed locally.
Print Control:
To prevent abuse, only users with “Permission to Print Ticket” can activate printing from the ticket details screen.
Reprints:
If a customer needs a second physical copy (for example, if they lost the first one), only users with “Permit Reprint Ticket” permission can do so, and the second printout will bear a “REPRINT” watermark.

Configuration: Administration -> Printing -> Settings
→ Checkbox “Limit re-printing”
→ Check the box to enable the restriction
→ Save settings


The first printout from the confirmation screen is considered the “Primary Printout.” Any subsequent attempts from the details screen will be treated as a “Reprint.”.

For more details please see our dedicated Support Article: Re-Print.

• Purpose: Ensures that cash collected from bundle sales is properly allocated to the correct bank for deposits during shift close.
• Impact: Improves accuracy of revenue tracking and deposit reporting for bundle sales. This change ensures redeemable items carry the necessary company information for proper financial reporting and deposit allocation.
  
  For more details please see our dedicated Support Article: Bundle Redeemable Item.

• Configurable Limit: Administrators can define the maximum tickets per manifest for each promotion within the Promotions module.
• Sales Enforcement: During ticket sales, the promotion applies only to the allowed number of tickets. Any additional tickets show a message indicating the promotion limit has been reached.
• Usage Tracking: Promotion uses are tracked across sales, cancellations, and ticket changes, ensuring correct application and accounting.
• Reporting: Transaction, ticket, and promotion reports reflect applied promotions and limits.
  
  This enhancement ensures controlled promotion application, preventing overuse while providing flexibility for demand generation campaigns.

Future Limit: Prevents moving a passenger too far into the future beyond their original trip time. Past Limit: Prevents moving a passenger too far back in time before their original trip time.
These configurations ensure that when a passenger is moved, the new trip must fall within a defined time window relative to the original departure, improving control and preventing invalid movements.

For more details please see our dedicated Support Article: Move.

Use Case: A user responsible for dispatch or manifest adjustments may need to perform operational tasks across multiple stations. Instead of requiring them to open a shift per station, the system should validate their access based on the assigned shift locations, not the opened shifts. They should be able to dispatch or edit manifests that originate from any of those stations, without opening a shift.

Operational Control Rules:
An open shift is not required to perform manifest actions.
The user must have the origin station of the manifest assigned under their Shift Locations (in Admin > Users > Shift Locations).
The system must not require the user to have an open shift at that station to execute these operations.

The following actions are allowed under this control:

• Dispatch manifest
• Change manifest status
• Change bus assignment
• Change capacity
• Bulk move passengers
  
  For more details please see our dedicated Support Article: Manifest.

Use Case: The new busbud_online payment method can be refunded from Busbud, and to avoid confusion, no Betterez emails should be sent when processing refunds for busbud_online.

Configuration:

• In admin/payments, add the ability to configure each payment method so the "Email refund receipts automatically" setting does not trigger.
• Under Options for each payment method, include a new checkbox config: "Prevent automatic emails for refund receipts".
• Leave the existing Busbud payment unchanged.
• Add the new busbud_online payment method and enable the correct Busbud agency (CAD, MXN).
• Ensure refund emails are set to "never" for busbud_online.
  / / For more details please see our dedicated Support Article: Busbud

Fare Type Availability: The fare type of the original ticket is no longer validated against availability on the new manifest.
Fare Type Limits: Passengers can be moved even if the target manifest has fare type restrictions or has already reached its limit for that fare type.
Previous Issue: Previously, tickets with certain fare types could not be moved to schedules that were restricted or sold out for that fare type. This behavior has been corrected so that movements are now allowed regardless of fare type restrictions.

For more details please see our dedicated Support Article: Fare Type

Use Case: Operators can have drivers sell additional services at bus side, items that may not have been declared or booked at the time of the ticket sale. For example: extra baggage, blankets, bringing a pet carrier on board.

Configuration: Administration -> Scanning, go to "Scanner app sales" subheading

Make sure to update to the latest driver app to see the latest features.

Use Case: Drivers are able to see both the scheduled arrival and departure times for their trip

Make sure to update to the latest driver app to see the latest features.

A manifest with "Operations" status is not sellable in any channel, and can not have passengers moved to the trip (similar to "cancelled" status). The manifest cannot be set to "Operation" status if there are passengers booked on this manifest.

Use Case: Operators who need to move vehicles from one location to another, for logistical planning rather than passenger transport.

For more details please see our dedicated Support Article: Manifest

Driver Assignment:

• Support multiple drivers per manifest, assigned by origin–destination.
• Validations prevent overlaps, enforce rest times, and check O&D continuity (warnings with bypass options).
• Driver O&D now appears on manifest printouts.
  
  Vehicle Assignment:
• Prevents assigning vehicles to conflicting manifests.
• Enforces vehicle rest times.
  
  Conflict Prevention:
• Blocks driver/vehicle conflicts across manifests.
• Allows multiple drivers on the same trip segment if validations pass.
  
  These updates ensure safer scheduling, accurate tracking, and compliance with rest requirements.

Manifest List View:

• Shows all manifests.
• Non-dispatched = read-only.
• Dispatched = editable (Driver, Mileage, Vehicle).
  
  Filtering: By date, driver, company, vehicle, and dispatch status. Review & Finalize:
• Manifests must be marked Reviewed before export.
• Users select a date range, confirm, then finalize.
• Once finalized, manifests are locked and cannot be resent. Export: Finalized data triggers a webhook and CSV export to SAP.
  
  This ensures accurate payroll, one-time exports, and reliable SAP integration

When enabled, this setting requires that any schedule created or edited must have both a brand and an operating company assigned. This prevents issues where unassigned schedules block integration, such as with the Driver Runs report to SAP, ensuring smooth dispatching and reporting.

The format is as follows:

• First 2 digits: represent the Operating Company (OpCo) (e.g., 02 or 03).
• Next 10 digits: represent the consecutive folio number for tickets.
• IKEY: replaced with our system’s unique ID.
  Additionally, a numeric code for the OpCo will be available to feed through the webhook, allowing external systems to concatenate and process ticket numbers consistently.

Use Case: Ensure there are no omissions to schedule configurations for operating company and brand.

Configuration: Administration > Sales Inventory > Sales Operations, checkbox for Operating company mandatory for schedules and Brand selection mandatory for schedules

Use Case: Operators who prefer to follow their own ticket sequencing and format can opt to use this feature for continuity. Note that when this is enabled, all future tickets will start their numbering sequence and increase by 1 for each ticket issued in the system.

Configuration: Administration -> Sales Inventory -> Sales Operations, checkbox for Allow operating companies to configure their own ticket numbers. Once enabled go to Administration > Operating Companies, create an operating company and go to subheading "Sequences". Ensure all your schedules are assigned an operating company to use sequences correctly.

The system will automatically calculate commission amounts per transaction based on the assigned percentage or fixed value:

• Before taxes: Price before taxes and commissions
• After taxes: Final price with taxes and commissions
• Fixed amount: stored directly without applying a calculation.
  
  Commissions are stored in two new transaction fields and support multi-currency. Totals are also summed to calculate the commission earned per shift.

To ensure accuracy, times are shown according to the time zone of each station, rather than the account’s default time zone.\ This enhancement aligns the Driver App with the manifest display, giving drivers clear and reliable trip timing details across multiple time zone

Use Case: For operators who have configured open return tickets, allow your passengers to redeem the open return for a different origin and destination than was booked on the first leg. Ex: customer can book A -> D and then use the open return to redeem for a C -> B ticket. The value of the open return is paid against the cost of the return for whatever O&D.

For more details please see our dedicated Support Article: Open Return

Contact support@betterez.com if you want this configured.

For more details please see our dedicated Support Article: Print Template

Use Case: For trips with seatmaps that have multiple seat classes (ex: VIP seats, and standard seats), operators may want to only sell the "VIP" seats for longer distance trips only to maximize revenue. In this case, create two fare tables, one for VIP where O&D prices are set to only long distance combinations, and another fare table for standard seats with all O&D combinations. Passengers will not be able to book the VIP class seats for the short haul trips that were not priced in the VIP fare table.

For more details please see our dedicated Support Article: Print Template

Configure your station longitude and latitude, with the ability to enter the google maps URL to pull the longitude and latitude automatically. These coordinates are then used to display the station location when looking at the back office routes and schedules.

For more details please see our dedicated Support Article: Location Information

Use Case: For operators who run closer to commuter style services. Opt to enable standing passengers to sell additional tickets in excess of your seated capacity. This is only for back office sales channels, and in the trip results we display to capacities, one for seated and one for standing.

Configuration:...

For more details please see our dedicated Support Article: Standing Passenger

Configuration: Administration -> Product Lines, select the product and configure the days in advance sales setting for back office.

Use Case: …

Configuration:

Use Case: Customer may create multiple profiles over their purchase history. In Betterez you are able to select one profile as the parent, and merge all other profiles into the parent. All history and loyalty points are moved to the main parent profile.

Configuration: The setting is available in any customer details page, the button to “merge” will be at the top right. If this option is not available right now in your account, please reach out to support@betterez.com and request to enable the customer account merge feature.

For more details please see our dedicated Support Article: Merge Customer

Use Case: Operators who want to allow drivers more autonomy where an incorrect ticket is scanned, the unredeem ticket option can be enabled in the scanning app.

Configuration: Work with Betterez support to enable or disable role permissions for unredemptions of tickets for your driver role.

Make sure to update to the latest driver app to see the latest features.

Use Case: For operators who have drivers using the app over multiple days, our current settings will retain yesterday's date for the trips view. For operators who want to always default the trips view to today’s date, this configuration will ensure drivers are always looking at their current days trip.

Configuration: Administration -> Scanning -> enable "Prevent wrong selected date"

Make sure to update to the latest driver app to see the latest features.

Use Case: Drivers can now sell trips with seatmaps. The driver app will pull the latest pricing for the seat, including any seat fees when selling the ticket with the driver app.

Configuration: Administration -> Scanning -> configure the "Scanner app sales" section with your product, fare types and payments to accept with onboard sales

Make sure to update to the latest driver app to see the latest features.

Use Case: In each manifest details page, under “comments”, a note of the ticket number and movement is made. This applies to all tickets moved.

Use Case: Allow customers to obtain a voucher that is not limited to an origin and destination when redeeming the voucher.

For more details please see our dedicated Support Article: Vouchers

• Loyalty Points: Tax is applied only to the portion paid with cash/credit, not to the value covered by points.
• Promo Codes: Tax is calculated on the discounted total, not the original fare.
• Mixed Payments: In combined cases (promo code + loyalty points + cash/credit), taxes are applied only to the net payable amount after all discounts and points are applied.
  This ensures accurate tax handling aligned with Transpais’s requirements.

• Configuration: In Reservation Rules, one or multiple brands can be selected for when the fee applies.
• Rules Handling: Time-based rules and fare class rules do not apply to this fee type. These options are greyed out and display the message “Only available for…” for clarity.
• Application in Connection Trips: Each fee is applied only to the brand of the ticket it matches, ensuring accurate brand-based charges across all journey segments.

• Auto 1:1 Matching: Tickets are automatically reassigned if the section, row, seat number, and destination match between the current and target manifest.
• Activation: A new button allows users to trigger the auto-assign process.
• Conflict Handling: If a seat is already taken in the target manifest, the ticket is flagged in red for manual assignment.
  This enhancement speeds up the manifest move process and reduces manual work while preserving flexibility for conflict resolution.

• Previous behavior: Shifts could only be printed immediately after closing; once signed out, agents lost access unless given Shift Reports permission.
• New behavior: After closing a shift, the “My Shift” screen will display the user’s most recently closed shift, allowing them to reopen it for printing.
  This change supports 2-step shift closing process, enabling managers and agents to double-check and print shifts without requiring extra permissions.

• Ticket Sales: Tickets sold from tax-exempt schedules will not include any tax calculation.
• Manual Sales: The same behavior applies when selling tickets manually; totals from tax-exempt schedules remain tax-free.
• Connections: No impact on connections, as this configuration applies only to the individual schedule.
  This enhancement ensures accurate pricing and compliance for services that must operate without tax applied.

Key Capabilities:

• Unified Booking: Customers can book trips involving multiple interline partners in a single transaction with one payment.
• Mappings Configuration: Support for mapping fare types, stations, and terms of service across operators.
• Itinerary Display: Clearly shows interline partners, departure/travel times, and associated brands or operating companies for each leg.
• Pricing: One price applied across the full interline journey.
• User Management: Authorized users can change or cancel their interline journeys (ONTC rules apply).
• Languages: Full English and French support.
  This enhancement simplifies cross-partner travel by removing the need to manually add interline items to the cart, improving the booking and reporting process for both agencies and customers.

• Included in the transaction.completed webhook
• Displayed in the Paid Items Report (new “Operating Company” field)
  This applies to all paid-in items (e.g., cash deposits, cheque exchanges, internal allocations), ensuring accurate reporting and reconciliation.

• By default, filters in Intelligence Reports are hidden after applying.
• A new admin/setup flag allows users to choose whether filters remain visible or hidden after applying, enabling quicker subsequent report edits.

Now, system administrators can configure the maximum number of distinct departure and arrival time options available. This improvement ensures that if the fastest options are unavailable (e.g., sold out), additional trip alternatives can still be displayed to customers, making it easier for them to complete their purchase.

• Bank accounts can now be assigned to a specific shift location and operating company.
• During shift closeout, tickets sold are automatically linked to the assigned bank based on shift location and operating company.
• The deposit amount is automatically calculated based on the above assignment.
• Users are restricted from closing multiple shifts across different locations, ensuring accurate reporting.

In scenarios where the operator want's to ensure an audit can take place of the user's shift close, they may opt to hide the total amount from the sales agent to have the manager review any discrepencies from cash reported to shift close sales.

Ensure users in the system are opening shifts at only the locations they are approved for by administration. This ensure sales agents are only opening shifts at their correct locations. Administration > Users, select a user and in the "Shift Locations" configuration, add one or more shift locations they are permitted to use.

Prevent continued ticket changes Administration > Setup, enable "Limit number of changes per ticket" and set the count for changes

Refund a customers ticket to a voucher instead of the original form of payment. Vouchers can also be configured to allow for any origin and destionation to be redeemed, regardless of what the original ticket was booked for. Administration > Sales inventory > Settings, enable "Override vouchers origin and destination rules" Administration > Setup, enter the "Refund expiration date" for how long a voucher refund lasts.

• Shortcode entry with Enter: Users can now type a station shortcode (e.g., VIC) and press Enter to auto-select the connected station.
• Auto field progression: Pressing Enter will automatically move the user to the next field (Origin > Destination > Departure Time).
• Improved dropdown filtering: Stations matching entered shortcodes are prioritized at the top of the dropdown list, ensuring quicker access.

Used when an operator wants to provide safer or more comfortable seating options for female passengers. Enables the sales agents for the operator to see female seated passengers and opt to assign another female to sit beside them during the booking process. Administration > Setup, enable "Show gender field on the simplified sales flow" and optionally "Gender field is required on the simplified sales flow"

In the back office booking, for origin and destination entry, and operator can type in a the designated short code. Ex: NYC for "New York City" and press enter to select a station quickly Operations > Stations, select a station and enter the "short code"