Coding is the method. Revenue management is the subject.
Every lesson starts from a question an operator actually asks, and ends with something that answers it. Nothing here teaches programming as an end in itself.
How every lesson is structured
The same six moves, every time. The fifth is the one that makes the difference.
Business question
Stated in the words an operator would use, not in the words a database would use.
Build prompt
A prompt you can copy, specific enough that the first result is close to useful.
Working example
Something that runs on synthetic data, small enough to check by hand.
Tests
Specific checks with known answers. If the tool disagrees with the source, the tool is wrong.
Operating complication
The real-world wrinkle that makes the naive version misleading. This is the lesson.
Optional RME connection
Where a supported RateHighway capability might add value, and what would have to be true first.
Lessons
Status is stated on every lesson. Two are being written; the rest are planned.
Check My Market Position
For the dates and classes I care about, where does my offer actually sit against comparable offers?
Understand Fleet Pressure
On which dates is demand pressing hardest against the fleet I actually have available?
Compare Booking Pace
Is this date building faster or slower than a comparable date, and how would I know?
Build a Pricing Assistant
What would I change today, and what is the reasoning I could show a colleague?
Build a Revenue Dashboard
How did we perform, and does everyone reading this page agree on what the numbers mean?
Connect a Tool to RateHighway Services
What has to be true before a tool I built may read authorised operational data?
The vocabulary that keeps causing arguments
Revenue management is not undercutting the nearest competitor. These are the ideas that decide whether a number means anything.
Comparability
Pickup date, return date, rental duration, pickup and dropoff location, vehicle class and class mapping, currency, taxes and fees. Change any one and you are comparing different things.
Supply and demand
Availability across the full rental period, fleet pressure, utilisation, booking pace and demand. A date is not busy because of pickups; it is busy because of occupied days.
Control and trust
Data freshness, rule conflicts, floors, ceilings, exceptions and failed rate updates. A price that was calculated correctly and never published is still wrong on the screen.
If a metric appears on a page you build, define it on that page. If a value depends on an assumption, put the assumption next to it.
Ready to build one?
The Playbook turns a lesson into a working tool. The modules give you a starting point that is already shaped like the problem.