Week 9 Session: Value-for-wait map

Reading one real system to tell apart an explicit value trade from a priority mechanism, using only what it actually publishes.

Week 8 asked you to map a policy that gives one class of people priority. This week’s system may or may not involve priority at all — the task is to work out which mechanism you’re actually looking at before you say anything else about it.

Before the session#

Read the Week 9 lecture first. Keep its three-way distinction in mind: the implicit value of an outcome, an explicit trade a system builds on purpose, and priority redistribution (Week 8) are not the same mechanism, and a single system can look like more than one of them at once.

Finding a system#

Find one real, publicly published system offering at least two options that differ in wait time — delivery-speed tiers at checkout, a paid queue-skip pass, standard versus expedited processing, or similar. Use only what the system actually publishes: a stated price, a stated time, a stated condition.

Building the map#

Answer these questions, in order, using only the published information:

1. What are the stated options? Record them as published — time, cost, and any other terms named.
2. What exactly changes between them? Time only, or also money, flexibility, certainty, or the outcome/service itself.
3. Is there a shared queue or order position? Does choosing the faster or slower option move you ahead of or behind other people in the same line, or are the options entirely separate processes with no shared position at all?
4. Classify the system. Answer this question directly: does this system change the value or attributes received, or does it change who is served first? Choose one — value/attribute exchange, priority redistribution, both, or cannot determine from published information — and justify your choice using only what you found in steps 1–3. If the published information doesn’t let you tell, say so; that’s a legitimate answer here, not a failed one.
5. What information would we need to judge whether the trade is worthwhile? Name what’s missing — how much people actually value the time saved or spent, how often each option is chosen, anything else a published policy doesn’t tell you. Don’t estimate it.

What’s out of bounds#

Don’t offer a fairness verdict, a pricing recommendation, or a redesign. Don’t claim any finding about willingness-to-pay beyond what this course’s sources actually measured in their own bounded contexts — Dietl, Voigt and Kuhn’s finding was about willingness to accept a longer wait for a shipping-cost saving in one online retail context, not a general claim about paying for speed, and it isn’t yours to extend to your own example.

In the session#

Bring your map. We compare across the room: whose system was clearly one mechanism, whose looked like both at once, and whose published information simply wasn’t enough to classify.

What this can and can’t show#

Reading a system’s published terms can tell you what it offers and roughly how it’s structured. It cannot tell you whether the trade is actually worth it to the people choosing it, or what they’d say if asked — that needs evidence this exercise doesn’t have.

Afterwards#

This is the last session before the Queue Case Study is due. Bring your log, your Week 7 queue map, your Week 8 priority map, and this week’s value map to it — the case study asks you to hold several of these mechanisms together in one real system, and to keep them as distinct there as you’ve kept them here.