How to Offer Preferred Lesson Times Without Hiding Standard Availability

Offer preferred lesson times as a clearly labeled subset of the feasible schedule—not as a replacement for it. First remove times that genuinely fail the student, instructor, vehicle, pickup, route, buffer, or policy checks. Then show the remaining standard options and make the route-friendly choices easier to notice with a badge, short recommendation list, or optional disclosed incentive.

The practical rule is simple: preferred times ⊆ feasible times. “Preferred” should describe why a valid slot is operationally better. It should not imply that other valid slots are unavailable, manufacture urgency, or turn an internal routing preference into a false scarcity claim.

This distinction sits one step after the seven checks that make a lesson slot truly available. Feasibility decides whether the school can keep the promise. Preference decides which feasible promise the school would most like the student to choose.

Keep three scheduling states separate

This classification avoids two opposite errors. Showing infeasible times creates bookings the school may later cancel. Hiding feasible standard times merely to steer demand makes the schedule look scarcer than it is.

The Federal Trade Commission’s current small-business guidance says an advertisement can mislead through what it states or omits, and that material qualifications should be clear and conspicuous. Its dark-pattern report specifically discusses interfaces that create false beliefs through bogus “almost sold out” messages and other artificial urgency. A booking calendar is part of the customer’s buying experience, so the overall impression matters—not only whether an individual label is literally true. See the FTC advertising guide and FTC dark-pattern report.

Decide what “preferred” means before adding a badge

A preferred time needs a rule that staff can explain and reproduce. For a pickup-based school, a useful rule may consider how the proposed lesson fits between the instructor’s actual previous and next commitments. It can also include the school’s configured start cadence and service buffers. It should not be a label applied manually whenever a particular hour is hard to sell.

Start with the same exact booking inputs used for availability:

• service and duration;
• student and usable entitlement;
• instructor and vehicle;
• pickup and drop-off;
• previous and next commitments;
• before- and after-service buffers;
• requested date and start time; and
• the current cart and attendance context.

Then apply a separate preferred threshold to the slots that already passed. For example, a school might classify a time as preferred when both adjacent travel legs stay within its route policy and leave the desired operating slack. The threshold must come from the school’s real routes, service model, and risk tolerance—not from a universal mileage or productivity benchmark.

Google’s Routes API can calculate a matrix across multiple origin-and-destination combinations, which is useful when evaluating several actual instructors or candidate times. Traffic-aware routing can incorporate current traffic conditions, but Google also documents a quality-versus-latency tradeoff. The result is still an input to a school policy, not a guarantee that traffic will remain unchanged. See Compute Route Matrix and traffic-aware routing options.

A worked schedule: show two choices and prefer one

Assume the following illustrative schedule. These numbers demonstrate the decision; they are not recommended buffers or travel limits for every school.

• The instructor’s prior commitment ends at 1:00 PM.
• The next fixed commitment begins at 4:00 PM.
• The proposed lesson lasts 60 minutes.
• The school applies a 10-minute buffer after the proposed lesson.

The calendar should not erase 2:00 PM simply because 2:15 PM produces a cleaner route. It should preserve the customer’s valid choice while making the operationally better option easy to understand. The separate guide to two-sided driving-lesson travel checks explains how the incoming and outgoing legs can fail independently.

Use a recommendation before using a discount

A preferred label may be enough. Test the nonfinancial presentation first:

1. Place a consistent badge beside the preferred date or time.
2. Add a legend such as “Preferred times fit this instructor’s route especially well.”
3. Offer a short suggestions view while leaving the complete feasible calendar accessible.
4. Measure selection and delivery outcomes without changing the price.

If the school later adds a discount or credit, disclose the actual benefit and its conditions before the customer selects it. Do not expose a reusable coupon code, imply that the standard price is a penalty, or preserve the benefit after the pickup, instructor, service, cart, or time that justified it has changed.

A time-limited incentive can be legitimate when the underlying opportunity really expires. The problem is not an honest deadline; it is a countdown or “only one left” treatment that does not correspond to real inventory or terms. Make the reason, value, and expiry visible enough for a customer to understand the choice on a phone without opening fine print.

What RouteOS currently implements

The RouteOS code-grounded feature report reviewed September 8, 2026 identifies RouteOS Route Incentives version 0.3.21 as implemented. It starts with slots already returned by the active LatePoint availability result and asks RouteOS Travel Availability to classify those exact candidates. It does not create nominal times from office hours alone.

When enabled and configured, the feature can:

• decorate preferred dates and times with visible and screen-reader treatment;
• present an accessible suggestions dialog grouped by date;
• scan a configurable one- to fourteen-day window and return a configurable one to ten suggestions;
• run with no financial incentive;
• optionally connect one active native LatePoint coupon to a short-lived, opaque offer; and
• recheck the current cart, item, visible slot, and travel classification before the benefit survives.

The suggestions dialog and coupon behavior are separately configurable. Preference rules remain part of Travel Availability, while Route Incentives controls how preferred choices are presented and whether a reward is attached.

Those are implementation capabilities, not proof that the feature is enabled on every RouteOS school, that every school uses Google Routes, or that a particular school will improve route density. Pickup data, provider credentials, travel policy, LatePoint availability, and feature settings must all be correctly configured. A provider failure can make a route result indeterminate; it must not be silently converted to a zero-minute trip or a fresh preferred claim.

When hiding a feasible time can still be legitimate

A school may intentionally withhold capacity for a real operational reason: an instructor is not assigned to public booking, a service is staff-only, a vehicle is reserved, the school has set a genuine booking horizon, or the slot violates a published channel or service policy. In those cases the time is not public inventory under that policy.

That is different from calculating a time as feasible and then concealing it solely to make preferred choices appear scarce. Keep the rule in the availability layer, apply it consistently, and let staff see why the slot was withheld. Do not call a feasible standard time “unavailable” merely because another option is more profitable or route-friendly.

Run this acceptance test before enabling preferred times

1. Capture the control. With synthetic students and addresses, record every feasible slot returned before preferred presentation is enabled.
2. Enable labels without a coupon. Confirm that the preferred set is a subset of the same feasible result and that standard choices remain bookable.
3. Test both route legs. Change only the pickup or the next commitment and verify that the expected classification changes. Use the driving-school scheduling software test when you need a broader adversarial demo.
4. Test stale context. Change the instructor, duration, pickup, attendee count, or cart after a preferred time appears. The old recommendation or reward should not authorize the changed booking.
5. Test provider uncertainty. Simulate a missing route or provider error. The interface should refresh, explain the next action, or require review—not claim that the time is preferred.
6. Test the optional benefit. Verify its displayed value and expiry, then confirm it is removed when its proof expires or the qualifying slot changes.
7. Test a narrow screen and keyboard. Standard times, preferred labels, the legend, benefit terms, and the return from suggestions to the full schedule must remain readable and operable.
8. Revalidate at confirmation. The final booking must rerun the consequential checks before it consumes payment or a lesson credit.

The decision rule

Choose transparent ranking when several feasible lessons exist and one subset better fits the route. Start with explanation, not a discount. Keep every genuinely public, feasible standard option available; mark preferred times consistently; disclose any benefit beside the choice; and invalidate the recommendation when its inputs change.

That approach improves the chance that customers choose operationally useful times without asking them to act on a false picture of the schedule.

Sources reviewed September 8, 2026. RouteOS behavior was checked against the supplied code-grounded feature report; public mechanism and presentation guidance was checked against the linked Google Routes and Federal Trade Commission materials.