VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

The Gold Standard of Yield Management | Bounding Unrecorded Demand Behind a Sell-Out

A sell-out records that a capacity limit was reached. It does not reveal how many additional qualifying requests arrived after the available units were exhausted. The same completed-sales record can therefore fit several different hidden-demand histories.

The short answer is to reconstruct the observation rule before estimating demand. In a simple fixed-capacity model, a sale count below capacity can identify the request count, while a count exactly at capacity supplies a lower bound. An upper bound needs additional evidence or an explicit model.

This guide develops original small ledgers, compatible histories and deterministic bounds. The services, capacities and requests are fictional. The calculations describe what the supplied records can identify; they do not recommend a price, booking policy or commercial forecast for an actual business.

eduKateSG · Yield Management

Find your next learning step

Separate completed sales from qualifying requests under a stated capacity and observation rule. Follow the worked sequence or choose the route that locates the first uncertain connection.

ROUTE 1 · CHAPTERS 1–5

Define the sales record

Define one qualifying request and distinguish exact observations from saturated ones.

ROUTE 2 · CHAPTERS 6–10

Reconstruct hidden requests

Construct hidden histories, add a justified maximum and inspect complete refusal logs.

ROUTE 3 · CHAPTERS 11–15

Change the observation rule

Audit duplicate events, cancellations, offer conditions and changing capacities.

ROUTE 4 · CHAPTERS 16–21

Audit and transfer

Separate forecasts from historical bounds and solve a changed ledger with refusal evidence.

ROUTE 5 · CHAPTERS 22–26

Practise and continue

Build an evidence card, repair overclaims and continue through the operational guides.

Full chapter contents · Yield Management subject guide

Chapter contents

Define the sales record · Chapters 1–5

1. Define the request and the capacity unit

2. Separate completed sales from underlying requests

3. Invert an uncapped observation

4. Invert a saturated observation as a bound

5. Reconstruct a six-session ledger

Reconstruct hidden requests · Chapters 6–10

6. Construct two hidden histories with the same sales

7. Explain why there is no finite upper bound yet

8. Add an evidenced maximum as a new model

9. Bound excess requests without confusing them with sell-outs

10. Use a complete rejection log when it matches the question

Change the observation rule · Chapters 11–15

11. Audit duplicate and unresolved request records

12. Keep cancellations outside the first observation equation

13. Preserve the time window and offer conditions

14. Allow capacities to differ without losing the session record

15. Use a sell-out time only with its observation assumptions

Audit and transfer · Chapters 16–21

16. Separate historical bounds from a population forecast

17. Recognise a closed channel as a different observation process

18. Solve an independent five-session example

19. Add complete refusal evidence to the changed ledger

20. Keep partial refusal evidence as an interval

21. Build an evidence card that another reader can reproduce

Practise and continue · Chapters 22–26

22. Repair three tempting explanations

23. Choose a practical learner route

24. Questions about sales and hidden requests

25. Continue through the relevant operational guides

26. Sources and a final request-count check

CHAPTER 1 OF 26 · Define the sales record

1. Define the request and the capacity unit

Back to contents

Imagine a fictional service that offers four identical places for one specified session. Each qualifying request asks for one place under a fixed offer. Requests are distinct, remain valid and arrive within the same stated observation window.

The service accepts qualifying requests until all four places are allocated. There are no cancellations, no-shows, group requests, reserved categories or changes to the offer in this first model. Those conditions isolate one capacity-censoring mechanism.

Call the qualifying request count D and the accepted-sales count S. Capacity C is four. The model stipulates that S equals the smaller of D and C: S = min(D, C).

The Yield Management subject guide connects dated capacity, booking states, commercial objectives and service delivery. Here the narrower task is to infer a hidden request count from a supplied observation rule. A real sales database requires its actual definitions before this formula can be assumed to describe it.

Contents · Next chapter

CHAPTER 2 OF 26 · Define the sales record

2. Separate completed sales from underlying requests

Back to contents

If two qualifying requests arrive while four places are available, the model accepts two and records S = 2. If four arrive, S = 4. If nine arrive, the accepted-sales record still shows S = 4.

The last two cases produce identical sales counts while differing in the request count. The capacity rule has compressed several possible demand values into one observed value.

This is not merely an incomplete spreadsheet entry. Even a perfectly accurate count of completed sales can omit information that the observation process never records. A more precise sales total cannot recover that missing distinction by itself.

A useful learner activity uses request cards and four place cards. Accept requests until the places run out, then keep the remaining qualifying request cards in a separate pile. If that pile is discarded before the record is made, a later analyst sees the same four accepted cards whether the discarded pile contained zero, one or many. The mechanism becomes visible before any forecasting method is introduced.

Contents · Previous chapter · Next chapter

CHAPTER 3 OF 26 · Define the sales record

3. Invert an uncapped observation

Back to contents

Under the exact first model, an observed sales count strictly below capacity identifies the request count. If S = 2 and C = 4, then D = 2. A larger D would have produced more accepted sales until the cap was reached.

This inference depends on the assumptions. If a channel was unavailable, the service rejected some otherwise qualifying requests or staff stopped accepting before capacity, the same observation could arise from another mechanism.

Write the conditional conclusion in full: under the stated acceptance rule and complete window, a non-saturated sales count equals qualifying requests. It should not become a universal statement that an unsold service has no hidden demand.

The word qualifying also matters. A casual enquiry, a duplicate message and a request for a different session are not automatically additional units of D. Define the event before counting it. A larger count built by combining incompatible statuses would not improve the estimate; it would change the underlying question while preserving a familiar demand label.

Contents · Previous chapter · Next chapter

CHAPTER 4 OF 26 · Define the sales record

4. Invert a saturated observation as a bound

Back to contents

When S = C = 4, the model permits D = 4, 5, 6 and every larger integer. The sales record establishes D ≥ 4, without establishing how far above four the requests may have gone.

In particular, a sell-out does not prove that any request was refused. Exactly four requests could have arrived and all could have been accepted. It also does not prove that only four requests existed.

These two limits prevent opposite overclaims. The evidence does not justify zero excess requests as an observed fact, and it does not justify a positive excess count merely from the capacity being full.

A responsible notation keeps the request value open: at least four. Replacing it with four can be a deliberate lower-bound scenario, but it should be labelled as such. Replacing it with a larger point estimate needs a stated estimation method and evidence. The appropriate conclusion follows from the observation rule, rather than from whether an analyst prefers an optimistic or conservative story about the service.

Contents · Previous chapter · Next chapter

CHAPTER 5 OF 26 · Define the sales record

5. Reconstruct a six-session ledger

Back to contents

Consider six fictional sessions, each with capacity four and the same stipulated acceptance rule. Their observed sales counts are 2, 4, 1, 4, 3 and 4.

SessionCapacityObserved accepted salesCompatible qualifying requests
A42Exactly 2
B44At least 4
C41Exactly 1
D44At least 4
E43Exactly 3
F44At least 4
Original fictional six-session ledger under S = min(D,C). Unsaturated entries are exact; saturated entries initially supply only lower bounds.

The accepted-sales total is 18. The non-saturated sessions contribute an identified total of six requests. Each of the three saturated sessions contributes at least four, so total qualifying requests are at least 6 + 12 = 18.

This is a complete account of what the stipulated sales ledger reveals before any upper limit or statistical model is added. Keep the individual session boundaries. A total alone can hide which observations were saturated, which were identified and which additional records would improve the answer.

Contents · Previous chapter · Next chapter

CHAPTER 6 OF 26 · Reconstruct hidden requests

6. Construct two hidden histories with the same sales

Back to contents

One compatible request history is 2, 4, 1, 4, 3 and 4, totalling 18. Every saturated session happened to receive exactly its capacity. There were no excess qualifying requests.

A second history is 2, 8, 1, 7, 3 and 12, totalling 33. Applying min(D, 4) to each entry produces exactly the same observed sales sequence: 2, 4, 1, 4, 3 and 4.

The two histories are explicit counterexamples to a claim that the sales ledger identifies total demand. Their disagreement is not caused by arithmetic error or different definitions of sales; both use the same supplied model.

A learner should verify the histories forwards, session by session, rather than merely compare their totals. The forward check confirms that each proposed request history actually reproduces the record. A large hidden total that assigns extra requests to a non-saturated session would fail this test. The observation rule constrains where uncertainty can occur, even when it leaves the saturated values open.

Contents · Previous chapter · Next chapter

CHAPTER 7 OF 26 · Reconstruct hidden requests

7. Explain why there is no finite upper bound yet

Back to contents

The saturated entries can be increased without changing their observed accepted sales. For example, increasing the last session’s requests from 12 to 100 still leaves its sales count at four under the model.

Therefore the six-session sales ledger alone supplies no finite upper bound on total requests. This is a mathematical statement about the specified observation rule, not a claim that real demand is physically infinite.

A real service has constraints that might justify additional limits, but those limits need evidence and a matching definition. A catchment population, qualified customer pool or complete request log could contribute information. An analyst should not invent a convenient maximum merely because an unbounded interval feels unhelpful.

The useful next question is which evidence would constrain the hidden part. More decimal places on an average of accepted sales would not do so. A bound on qualifying requests per saturated session could. Naming the missing relationship directs data collection toward the uncertainty the existing record cannot resolve.

Contents · Previous chapter · Next chapter

CHAPTER 8 OF 26 · Reconstruct hidden requests

8. Add an evidenced maximum as a new model

Back to contents

Now introduce an additional exercise condition: no session could have received more than ten qualifying requests. This is a new constraint, so the earlier 12-request history is no longer admissible under the changed model.

The three non-saturated sessions still contribute six requests exactly. Each saturated session now contributes from four to ten. Total qualifying requests therefore lie between 6 + 3 × 4 = 18 and 6 + 3 × 10 = 36.

Both endpoints are attainable. Use requests 2, 4, 1, 4, 3, 4 for the minimum and 2, 10, 1, 10, 3, 10 for the maximum. Applying the capacity rule returns the observed sales in both cases.

The mean request count across these six included sessions can therefore range from three to six at its attainable endpoints. It is not identified as the observed mean sales count of three. The upper-bound scenario is also not automatically a forecast. The deterministic interval states which request histories remain compatible with the supplied constraints.

Contents · Previous chapter · Next chapter

CHAPTER 9 OF 26 · Reconstruct hidden requests

9. Bound excess requests without confusing them with sell-outs

Back to contents

Define excess qualifying requests in a session as D − S under the stipulated acceptance rule. This equals zero when demand does not exceed capacity and equals D − C when it does.

For the capped ten-request model, total excess requests range from zero to 36 − 18 = 18. Three sell-outs can coexist with zero excess requests if each received exactly four requests.

The fraction of sessions that sold out is three out of six. It describes a saturation event in the observed record. It does not identify the fraction with demand strictly greater than capacity or the number of additional requests in those sessions.

Keep these quantities in separate labelled lines: saturated sessions, excess-request sessions and excess units. They answer different questions. A service could have many sessions just reaching capacity and few refused units, or fewer heavily oversubscribed sessions with many excess units. The sales ledger needs additional evidence to distinguish those patterns. Calling all of them unmet demand without a unit and definition conceals the distinction.

Contents · Previous chapter · Next chapter

CHAPTER 10 OF 26 · Reconstruct hidden requests

10. Use a complete rejection log when it matches the question

Back to contents

If the service records every qualifying request it refuses solely because capacity is exhausted, and the count uses the same unit and window, an additional rejection count R can identify requests through D = S + R.

For the six sessions, suppose verified rejection counts are 0, 3, 0, 2, 0 and 1. The reconstructed request history is 2, 7, 1, 6, 3 and 5, totalling 24. The rejection total is six, matching 24 − 18.

That is an exact reconstruction under the augmented exercise conditions. It differs from guessing a hidden value for each sell-out. The extra log has supplied the missing observations.

In a real record, an unsuccessful enquiry is not automatically a qualifying capacity refusal. Duplicate contacts, unsuitable dates, unavailable features, price objections and incomplete requests need appropriate classification. The root guide already makes this distinction. A useful rejection ledger improves identification only when it measures the event the demand account actually defines.

Contents · Previous chapter · Next chapter

CHAPTER 11 OF 26 · Change the observation rule

11. Audit duplicate and unresolved request records

Back to contents

Suppose a saturated session has four accepted units and three refusal messages. If two refusal messages concern the same one-place request, treating all three as distinct requests would inflate D.

A verified request identity rule should distinguish repeated contact from a new request. The rule belongs in the evidence note alongside the sales and capacity definitions. Names or message counts alone may not establish uniqueness.

If one refusal record remains unresolved, preserve an interval rather than choosing its interpretation to make the total look tidy. For example, four accepted requests and between two and three distinct qualifying refusals imply between six and seven qualifying requests for that session.

This is a different uncertainty from capacity censoring itself. One arises because a class of requests was not observed; the other arises because additional records cannot yet be classified or linked reliably. Combining them can be necessary, but the account should retain their separate causes. That makes a later correction traceable and shows which evidence would narrow the interval.

Contents · Previous chapter · Next chapter

CHAPTER 12 OF 26 · Change the observation rule

12. Keep cancellations outside the first observation equation

Back to contents

Our equation S = min(D, C) treated S as accepted sales under a fixed, non-reopening allocation. It did not describe final attendance after cancellations or no-shows.

If bookings can be cancelled and capacity resold, the total number of accepted booking events can exceed the number of places available at one moment. Final occupied places can also be lower than the number of qualifying requests. Either change breaks the simple interpretation unless its additional flows are explicitly recorded.

A complete account might need initial acceptances, cancellations, reissued availability, later acceptances and final use. Those are different states, not interchangeable counts of the same event.

The existing article on checking capacity across every night of a booking addresses connected dates and whole-stay feasibility. Our one-session, one-unit model deliberately isolates a different question. Before transferring the bound to an actual booking service, establish whether the observed count follows the simplified acceptance process or requires a richer ledger.

Contents · Previous chapter · Next chapter

CHAPTER 13 OF 26 · Change the observation rule

13. Preserve the time window and offer conditions

Back to contents

A request count is conditional on an offer, a service period and an observation window. Changing the price, inclusions, eligibility or channel visibility can change which requests arrive and which are recorded.

Our toy model treats D as an exogenous count of qualifying requests for the supplied offer. That assumption lets us ask what the capacity rule hides. It does not establish what real customers would have requested if a sold-out offer had remained visible or its conditions had changed.

For an actual study, distinguish observed refusals from counterfactual requests that might have occurred under different availability. The second question needs a behavioural and observation model, not just a larger sales spreadsheet.

This boundary also prevents a misleading comparison across periods. A higher inferred request total under a different offer is not automatically evidence that underlying interest rose for an unchanged service. Keep the conditions with the number. The mathematical reconstruction becomes useful when the event being reconstructed remains stable enough for the intended comparison.

Contents · Previous chapter · Next chapter

CHAPTER 14 OF 26 · Change the observation rule

14. Allow capacities to differ without losing the session record

Back to contents

Consider a second small ledger with capacities two, three and four, and sales two, three and three. The first two sessions are saturated. The third is not. The compatible request counts are at least two, at least three and exactly three, respectively.

Without another restriction, their total is at least eight and has no finite upper bound. Now supply an independently justified maximum of eight qualifying requests per session. The total lies between eight and nineteen. The lower endpoint uses requests two, three and three; the upper uses eight, eight and three. Both histories reproduce the supplied sales when each session’s own capacity is applied.

The sales value three has different meanings in the second and third sessions. At capacity three it may hide additional requests. At capacity four it identifies three requests under our acceptance model. A column of sales without the matching capacity column loses this distinction.

Do not replace the three capacities with their average and invert the sales against that average. The observation rule operated separately in each session. Reconstruct those separate constraints first, then combine them if the question asks for a total.

Contents · Previous chapter · Next chapter

CHAPTER 15 OF 26 · Change the observation rule

15. Use a sell-out time only with its observation assumptions

Back to contents

Suppose a session’s fourth accepted request arrives at noon and the session then closes. Knowing that time locates when the capacity was exhausted. It does not count how many qualifying requests would arrive after noon.

One compatible history has no later requests. Another has six later qualifying requests that the sales counter cannot accept. Both can have exactly the same first four arrival times and the same noon sell-out time. Earlier exhaustion may be commercially useful information, but it does not by itself supply a numerical upper bound on the later total.

A complete request-arrival log could answer a different question. A credible bound on the number of later qualifying arrivals could also narrow the interval. Either would be additional evidence. A forecasted arrival rate is a model input, not an observed count merely because it is expressed per hour.

Keep the timestamp with the event that generated it: fourth acceptance, channel closure or manual status change. Those can occur at different times in practice. A precise clock reading does not resolve an ambiguous event definition.

Contents · Previous chapter · Next chapter

CHAPTER 16 OF 26 · Audit and transfer

16. Separate historical bounds from a population forecast

Back to contents

The interval eighteen to thirty-six in our six-session example concerns those six supplied sessions under the maximum-ten condition. It is not a confidence interval for a future session’s demand and does not establish how often any hidden history occurs.

A probability model could assign different probabilities to compatible histories. That would require additional assumptions or evidence about request generation, comparable sessions and the recording process. The arithmetic alone supplies a feasible set. It does not supply a probability distribution over that set.

Likewise, averaging only the unsold sessions is not an automatic repair. Those sessions are precisely the ones whose requests remained below capacity. Their mean describes that selected subset. Treating it as the mean of all sessions assumes away the selection created by the capacity threshold.

An investigator can still report the subset honestly: these three uncapped observations are two, one and three. What cannot follow from that sentence alone is that each saturated session also had two requests. Such an imputation would contradict sales of four before any forecasting question is considered.

Contents · Previous chapter · Next chapter

CHAPTER 17 OF 26 · Audit and transfer

17. Recognise a closed channel as a different observation process

Back to contents

A blank request count is not necessarily a zero. If a booking channel disappears when availability reaches zero, people who might otherwise have requested the offer may never enter a recorded request. A refusal log from that channel can then be incomplete for the question being asked.

There are two distinct unknowns. The first is a qualifying request that occurred but was absent from the sales count. The second is behaviour that might have occurred had the offer remained available and visible. Our simple equation concerns a supplied count D of qualifying requests under a stated observation model. It does not automatically identify that counterfactual second quantity.

Record whether the channel remained open to requests, whether refusals were retained and whether another channel handled later contacts. If these facts are unknown, preserve the uncertainty in the evidence note. Adding zero rows for unobserved periods creates apparent completeness without establishing it.

The useful response can be to improve instrumentation before estimating a larger total. Counting correctly defined requests while capacity is unavailable changes the evidence available for the next analysis. It does not retroactively reveal every missing event in an old record.

Contents · Previous chapter · Next chapter

CHAPTER 18 OF 26 · Audit and transfer

18. Solve an independent five-session example

Back to contents

Now change both capacity and the ledger. Five sessions each have capacity five. Their sales are five, two, five, four and one. Assume the same one-unit request and acceptance rule, and supply an independently established maximum of nine requests per session.

Pause before calculating a mean. Which sessions identify their requests exactly? Which give only a range? The second, fourth and fifth identify two, four and one. The first and third each allow any integer from five through nine.

Total sales are seventeen. The smallest compatible request total is therefore seventeen. The largest is nine plus two plus nine plus four plus one, or twenty-five. Across these five sessions, the compatible mean ranges from 3.4 to 5 requests. The excess-request total ranges from zero to eight.

Construct the endpoints rather than trusting the interval’s appearance. Requests five, two, five, four and one produce seventeen. Requests nine, two, nine, four and one produce twenty-five. Apply the capacity-five rule to both histories and the same sales return. This is a changed example, not a rescaling of the earlier table’s answer.

Contents · Previous chapter · Next chapter

CHAPTER 19 OF 26 · Audit and transfer

19. Add complete refusal evidence to the changed ledger

Back to contents

For the changed five sessions, suppose a complete, independently checked refusal log gives three, zero, one, zero and zero qualifying requests refused solely because capacity had been exhausted. Each refusal represents one distinct one-unit request, and accepted requests are excluded from that log.

Under those conditions, add sales and refusals session by session. Requests become eight, two, six, four and one. Their total is twenty-one, and their mean is 4.2. Four qualifying requests were unfulfilled because of the supplied capacity rule.

These values fit the earlier interval seventeen to twenty-five and the maximum-nine restriction. They also pass the stronger forward check: the minimum of eight and five is five; the minimum of six and five is five; the remaining sessions reproduce two, four and one.

The refusals provide new information. They do not demonstrate that twenty-one was already inferable from the original sales. Before the log arrived, several totals were compatible. After a valid complete log arrived, those alternatives were ruled out by additional evidence. Keeping these stages separate is the point of the exercise.

Contents · Previous chapter · Next chapter

CHAPTER 20 OF 26 · Audit and transfer

20. Keep partial refusal evidence as an interval

Back to contents

Suppose instead that one capacity-five session sold five units and has four possible refusal records. Two are verified distinct qualifying requests. Two more may be repeats of those same requests or may be additional qualifying requests. No other request events are missing, according to the supplied audit condition.

The number of qualifying refusals lies between two and four. The session’s request total lies between seven and nine. Seven uses both unresolved records as duplicates; nine uses both as additional distinct requests. If the evidence permits both arrangements, neither endpoint should disappear from the report.

That completeness condition matters. Without it, seven remains a lower bound from the verified refusals, but nine need not be an upper bound: other unrecorded qualifying refusals could exist. The uncertain classification of known records and the possible absence of other records are separate sources of uncertainty.

This is also why a deduplication percentage cannot simply be borrowed from a different log. The record-level possibilities need an applicable audit or model. Write down which uncertainty the interval represents before presenting its numerical width.

Contents · Previous chapter · Next chapter

CHAPTER 21 OF 26 · Audit and transfer

21. Build an evidence card that another reader can reproduce

Back to contents

For each session, retain its identity, observation window, capacity and sales. State the request unit and acceptance rule. Add the saturation flag derived from the matching capacity, rather than inferring it from a visually large sales number.

Next record any additional restriction with its origin. A maximum of nine must have an evidence basis or be labelled a fictional exercise assumption. A complete refusal count needs its event definition, deduplication rule and coverage statement. A manually estimated number should remain labelled as estimated.

The resulting lower and upper request bounds should be reproducible from these fields. If a bound changes, another reader should be able to identify whether capacity, sales, log coverage or an assumption changed. Keeping only the final mean removes that audit trail.

Finish with the forward check. Every proposed reconstructed history must reproduce every observed sales entry under the stated rule. This is necessary for compatibility. It does not establish that the reconstructed history is the actual one, nor that accepting more requests would have been operationally or commercially preferable.

Contents · Previous chapter · Next chapter

CHAPTER 22 OF 26 · Practise and continue

22. Repair three tempting explanations

Back to contents

“Every sold-out session had demand equal to capacity” replaces a lower bound with an equality. Repair it by saying that a saturated observation gives at least capacity qualifying requests under this model. Use an equality only when extra evidence establishes no additional requests.

“Three sell-outs mean at least three lost requests” makes a different mistake. A session can reach capacity exactly and receive no more requests. Three sell-outs establish three saturated sessions; they do not establish positive excess in any one of them.

“We can recover hidden requests by substituting the average of quieter sessions” introduces an imputation without a model that justifies it. Such a substitution can even fall below the already accepted count. First preserve the per-session constraints. Then explain any statistical estimation method and why it is appropriate for this evidence.

A fourth repair is linguistic but consequential: call the calculated quantity requests, accepted sales or qualifying capacity refusals as appropriate. Do not silently turn all three into “customers”. One person can make several contacts, and the exercise’s one-unit request convention needs to remain visible.

Contents · Previous chapter · Next chapter

CHAPTER 23 OF 26 · Practise and continue

23. Choose a practical learner route

Back to contents

For repair practice, use three cards with the same capacity four and sales three, four and four. Ask the learner to write one exact request count and two lower bounds. Then request two distinct hidden histories. The learner has understood the observation rule when both histories reproduce the cards and the uncertainty remains attached to the saturated entries.

For stabilisation practice, vary one condition at a time. Add a justified request maximum, then replace it with a complete refusal log. Ask which conclusions become narrower, which become exact, and which still depend on the acceptance model. Avoid changing price, capacity and cancellation rules simultaneously before those distinctions are secure.

For extension practice, introduce a partially audited refusal log or different capacities across sessions. Require endpoint constructions and a forward check. An unsupported exact answer is less complete than a correctly explained interval.

A final explanation task helps transfer: describe why a full classroom, fully booked appointment list or exhausted stock display can conceal different amounts of unrecorded interest. Then identify one way each situation departs from the one-unit model. The shared reasoning transfers; the operational assumptions need fresh checking.

Contents · Previous chapter · Next chapter

CHAPTER 24 OF 26 · Practise and continue

24. Questions about sales and hidden requests

Back to contents

Can a session be sold out without losing a request? Yes. In our model, D equal to C gives full sales and zero excess. Evidence of saturation alone cannot distinguish that case from D greater than C.

Does unsold capacity always identify demand? Only under the stated rule that every qualifying request is accepted while capacity remains, with the supplied timing and no cancellations or other restrictions. Real prices, eligibility, visibility and booking controls can invalidate that simplified observation equation.

Is a waitlist a complete refusal count? Not automatically. Joining may be optional, repeat entries may occur, and some contacts may use another channel. Its coverage and event definition need checking before an equality uses it.

Do these bounds choose the best capacity or price? No. They describe what the stipulated observations identify about qualifying request counts. A decision about capacity or price also needs costs, service constraints, behaviour and an objective. Better historical measurement is an input to that decision, not a substitute for it.

Contents · Previous chapter · Next chapter

CHAPTER 25 OF 26 · Practise and continue

25. Continue through the relevant operational guides

Back to contents

For the broader relationship between availability, timing, customer promises and business decisions, return to The Gold Standard of Yield Management. For a different mathematical question with a fully supplied demand distribution, read valuing protected capacity through demand tails. That article evaluates capacity consequences; this one asks what an incomplete sales history can establish before such a distribution is assumed.

For inventory that connects several service dates, use checking capacity across every night of a booking. For interpreting operational performance measures, continue to hotel occupancy, average daily rate and RevPAR. Those measures answer questions about realised operation, not the missing request counts by themselves.

For related stock-out settings, inventory reorder points and safety stock explains replenishment protection. Fashion replenishment under uncertainty follows the decision to produce more, while inventory rebalancing follows movement of existing stock. Read these for their different decisions; a stock-out signal needs an observation model in each setting.

For the wider learning map, use How X Works and The Gold Standard of Education: learning transfers into life. The transferable skill here is preserving the difference between an observation and the hidden histories that could produce it.

Contents · Previous chapter · Next chapter

CHAPTER 26 OF 26 · Practise and continue

26. Sources and a final request-count check

Back to contents

Mark Ferguson and Carrie Queenan’s Starting with Good Inputs: Unconstraining Demand Data in Revenue Management, published on 1 May 2009, provides specialist teaching context for why capacity constraints limit what sales reveal about demand. The public article page was checked on 23 October 2026. The numerical ledgers and endpoint constructions here are original fictional examples, not data or results taken from that case.

Our calculations use a deliberately narrow observation rule: S equals min(D,C), with distinct qualifying one-unit requests, known capacity, the supplied window, no cancellations and acceptance whenever capacity remains. Maximum-request conditions and complete refusal logs are additional inputs, introduced only where stated. Removing those inputs can widen the compatible set.

To check your final explanation, cover the request column and reconstruct what sales alone establish. Then uncover the added evidence and identify exactly which alternatives it removes. Finally, put the proposed requests through the capacity rule and recover the sales.

That sequence gives a reader something more useful than a guessed hidden total: a clear account of what is observed, what is conditional, and what further record would resolve the uncertainty. Carry those distinctions into a new setting before carrying over its answer.

Contents · Previous chapter · Return to Yield Management