Revenue management module — JetSetGo MCP reference

The revenuemanagement module gives operators a service-level view of how scheduled departures are performing, plus two configuration surfaces on each service: which price type applies to it, and free-text operational comments. Analytics come from REST endpoints; the pricing-configuration and comment writes go through GraphQL.

What the operator uses it for

Three jobs. First, demand review: list services with their availability and revenue data over a date range or for particular routes and resources, and pull the booking-velocity curve — how sales accumulated ahead of departure — for selected services. Second, pricing configuration: assign (or clear) a service's price-type id, pointing an individual departure at a Peak/Off-Peak-style label defined in the pricing catalogue. Third, coordination: create and update comments attached to a service so staff can record context — weather concerns, staffing notes, pricing decisions — alongside the numbers.

The module is deliberately read-mostly. Services themselves are created and edited in the schedule module; this module observes them and annotates them.

Where it sits

Downstream of scheduling: every entity here is a scheduled service (departure). Sideways of the fare catalogue: the price-type assignment references labels owned by the pricing module, and changing one affects how that service's fares are labelled and resolved at quoting time. The analytics reads aggregate booking data produced by the sales pipeline. Comment records hang off services and are independent of money movement.

Key concepts

Service — one scheduled departure; the unit everything in this module addresses.
Availability/revenue listing — REST-backed per-service figures used to spot under- or over-performing departures.
Booking velocity — the cumulative sales curve ahead of departure, optionally restricted to chosen services.
Price-type assignment — the price type applied to one service; null clears it back to unlabelled.
Service comment — a short operator-authored note attached to a service.

Tools

Tool	Class	Purpose
`revenuemanagement_services_list`	Read	List services with availability/revenue data; filters: date range, route, resource.
`revenuemanagement_booking_velocity`	Read	Booking velocity curve; optional list of service ids.
`revenuemanagement_comments_list`	Read	List a service's comments, newest-updated first.
`revenuemanagement_comments_save`	Guarded write	Create a comment (service id + text) or update one (id + text).
`revenuemanagement_set_service_pricing`	Guarded write	Set a service's price-type id; null clears the assignment.

Rules worth knowing

Create vs update is decided by id presence on revenuemanagement_comments_save: omit id and a service_id plus comment text are required; supply id and only the comment text changes.
price_type_id: null is meaningful on revenuemanagement_set_service_pricing — it removes the assignment rather than being rejected.
Writes are non-destructive in both cases; neither tool can delete anything.
Reads degrade gracefully. When a tenant does not track the service→resource or service→price-type relationships, comment listings and pricing-write results fall back from resolved names to bare ids instead of failing.
Enriched write results. A successful revenuemanagement_set_service_pricing returns the service's date, departure time, and status, plus resource and price-type names where tracked.
Explicit tenant required on writes, matching all guarded modules; reads accept the server default tenant when none is supplied.
Analytics shapes are endpoint-defined. The two REST reads return whatever the revenue-management endpoints produce (availability, revenue, and velocity series); agents should treat their payloads as opaque reports rather than assuming a fixed schema.

Schedule — owns the services this module analyses, prices, and annotates.
Pricing — defines the price types assigned to individual services here.
Business rules — conditional adjustments whose effects show up in the demand picture these reads expose.