Operations and Content Quality

From the communication protocol to the game-day service

Take out your Week 10 communication protocol and the log entry for game 2. The log shows one decision, a one-day move, passing cleanly through the company. A game-day appearance contains many such steps.

Someone checks the agreement and books travel. Someone translates the schedule. Someone makes sure no photo is posted before the performer approves it. The fans see a short performance during breaks in the game. Behind it sits a week of work.

This week is about that whole chain of work. Operations management is the arranging of people, time, information and decisions so that a promise is delivered, again and again.

In a factory, the resources are materials and machines. In a performance business, they include rehearsal time, travel, translation, venue access and trust. The output is more than the performance itself. It includes a safe working day, a corrected mistake and a relationship that can continue.

A reliable service is one in which the important conditions hold every time, while each performance can still feel fresh. The show can change from game to game. The conditions on safety, consent, timing and pay should not. Reliability is about those conditions and about the process that makes them likely to hold.

The practice scenario, which is invented for learning, continues with the 12-week test of Option A · Expansion (expand cheerleading and sports-entertainment talent management). Game 2 is coming up, and a third team has just asked for an appearance of its own. This week's question is: how can a creative service become reliable, and how do we know how much work the company can take on?

Where this week fits

Week 10 built a communication protocol: who tells whom, who decides and how corrections are recorded. Week 11 places those messages inside the whole service and marks where work passes between people. The result is a service blueprint with a capacity check. Week 12 then takes the blueprint's top rows and asks who pays for the service and who only watches it.

An operation is a chain of promises

Many students first meet operations through factories, where a process turns inputs into outputs. Services and creative work add something: the customer is often present, and the output is partly created in the moment. A game-day appearance depends on the performer, the arena staff, travel, the home team's schedule and the mood of the fans.

Five questions describe any operation.

1. What promise is being made? A public announcement may promise a date and a performer. A private message may add a condition, such as a call time. If the promise is not written down, people plan against different versions. The Week 10 decision log is the bridge: it travels with the plan and says what is approved and what is still conditional.
2. What actions must happen to keep the promise? A process is a sequence of actions and decisions, including work done by customers, partners and suppliers. For a game-day appearance, the process runs from a briefing through the checks, travel and warm-up to the performance and a debrief.
3. Which resource limits the process? This is capacity, discussed below.
4. Where can information or responsibility be lost? These are handoffs, the points where work or information passes from one person to another.
5. What happens when the plan no longer fits? This is exception handling and recovery. A performer may fall ill, the arena may change the running order, or a translation may change the meaning. The operation needs a way to notice the problem, stabilize the situation, tell people honestly and learn from it.

The fifth question matters because no plan covers everything. A good operation expects exceptions and decides in advance who acts when one happens. It does not depend on every person being perfect.

A service blueprint: the work seen from both sides

Bitner, Ostrom and Morgan (2008) describe the service blueprint, a one-page map that shows a service as the customer experiences it and the work behind it. It helps a company see that a promise which looks simple to the customer depends on many actions the customer never sees. A blueprint has four layers, read from top to bottom.

• Customer actions: what the customer does and expects. A game-day appearance has two kinds of customer. The home team pays, and the fans watch.
• Frontstage actions: what the customer can see, such as the performance and the performer's greeting to the fans.
• Backstage actions: work that supports the service out of sight, such as Mina's checks and the translated schedule.
• Support processes: outside systems and partners the service depends on, such as the arena, the home team's event staff and payment.

A line of visibility separates what the customer sees from what stays backstage. The purpose of the map is to ask, at each step, where a failure could happen and who could act on it.

Blueprints simplify. A map can make work look tidier than it is, and it can hide informal effort and exceptions. So show the map to the people who do the work, ask them where it is wrong, and add their notes.

Worked example: a game-day appearance blueprint

This blueprint follows one appearance in the practice scenario, from the request to the follow-up. The roles come from the Week 8 organization chart, and the message routes come from the Week 10 protocol.

Three things stand out. First, most of the work is backstage, and most of it happens before game day. Second, every handoff has a named sender and receiver, taken directly from the Week 10 protocol. Third, the customer column holds two groups with different roles: the home team pays, and the fans only watch. Week 12 will start from that column.

The blueprint should also show a quality boundary. Some variation is part of the value: the performer may adapt the greeting to the crowd, or the warm-up to the arena. Other conditions are protections. Consent cannot be assumed from enthusiasm, and the 12-hour rest rule cannot disappear because the schedule is tight. Marking the difference keeps creativity from being confused with permission to weaken a safeguard.

Capacity and bottlenecks

Capacity is the amount of work a process can complete to a stated standard in a stated time. It is different from the number of people in a company. A person may be available in general but not in the week that matters. A large audience adds demand, not capacity.

A bottleneck is the resource that limits the flow of the whole process. In a small creator-led company, it is often the founder's approval time. It may also be a coordinator, a translator, a venue, or cash that must be paid before the work is delivered. The bottleneck can move. A process that works in an ordinary week may fail when two games fall close together.

Worked example: can Mina take on a third team?

In test week 7, a third team contacts Judy. It asks for an appearance at its own home game on the Saturday of test week 8. It would be the third team in the test, after the home team and the second team Judy is already talking to. That Saturday is open for her because game 2 has moved to Sunday.

The third team is ready to discuss a fee. Before Judy answers, the company checks capacity.

• Mina has 10 hours a week for the test, as set in the Week 5 goal tree.
• In an ordinary test week, her test work takes about 3 hours: the weekly check-in, updating the decision log and answering messages.
• Each appearance needs about 4 more hours of checks and coordination in the week before it (stage 2 of the blueprint). So the week before a game takes about 7 hours.
• She also spends about 1 hour briefing the partner, the home team's event staff, who handle game-day logistics. On game day, the liaison and the translator are on site.

In Week 6 the partner briefing was about 1 hour a week. From test week 6, Mina and the event staff replace the weekly briefing with one combined briefing in each game week, so the table shows it in test week 8 and not in test weeks 6 or 7. Game 2 is on the Sunday of test week 8, so its checks fall in test week 7. The third team's game would be on the Saturday of test week 8, so its checks would also fall in test week 7.

The calculation finishes like this: 3 + 4 + 4 = 11 hours in test week 7, which is 1 hour more than Mina's 10. On these estimates, Mina's time would be the bottleneck in that week. A bigger audience or a higher fee would not add hours. The check is only as good as its estimates: it shows that the plan does not fit as written, not whether the appearance would succeed.

One hour sounds small, but it matters. The 4-hour estimate has no margin, and the Week 9 audit found that Mina used all 10 reserved hours in the week before game 1. The checks most likely to be squeezed are the ones that protect people, such as the rest rule and the photo rules. The partner does not help here either, because it handles only the home team's games.

There is also a second possible bottleneck. Appearances on Saturday and Sunday may break the performer's 12-hour rest rule, whatever Mina's hours are. So the performer and the liaison must be consulted before anything is offered. The company has three choices, and each has a cost.

• Offer a later date. An appearance in test week 9 would put its checks in test week 8, which would then total 8 hours. The third team may not accept.
• Move some regular work. If the bookkeeper updated the decision log in test week 7, Mina's total would fall to about 10 hours. That leaves no margin, and it works only if the bookkeeper agrees in writing and has the time.
• Decline during the test. The goal tree promised two games, not three. Declining keeps the test clean, but the company loses a chance to learn whether a third team will pay.

Under the goal tree, a new agreement is Judy's decision. Mina opens a log entry with the status proposed and attaches the capacity table. The table does not make the decision. It shows what each choice costs before anyone makes a promise.

The brief and the exception rule

Handoffs raise the cost of coordination. Each one may need a clarification, a translation or another approval, and across borders these take longer. A short brief that travels with each appearance reduces this cost. It states:

• the promise, with the date and place;
• the people affected and the decision owner;
• the safety conditions and what is still unknown.

The brief must be short enough to use during real work. A brief protects people only if someone reads it at the moment it matters. If the performer never opens a ten-page brief, it cannot prevent a mistake; it just sits in a folder. That is why the brief in the scenario is one page, in Korean and in Chinese, and why the liaison asks the performer to say back the call time.

The company also needs a rule for exceptions. If the arena changes the running order, who may approve the change? If the performer cannot attend, who tells the home team, and who protects the performer from pressure? A flexible operation gives named people the authority to act when the plan no longer fits, and it records what changed and why.

Four levels of quality

A quality standard starts with the promise and the people it affects. The home team cares about timing and a good show. The performer cares about safety, consent, pay and rest. These interests overlap but are not the same, and a game can look like a success from the stands while hidden costs fall on the performer or on Mina. So quality is specified at four levels.

A single overall score is convenient, but it can hide a failure at one level behind good results at another. A great show does not make up for a broken rest rule.

Checklists help with tasks that repeat or carry high stakes. But a tick shows only that a box was completed. For each item, ask whether it needs evidence, a professional judgment or the affected person's own confirmation. The photo approval, for example, needs the performer's written confirmation, not Mina's tick.

Quality also depends on people speaking up. If reporting a problem costs someone future work, the records will look cleaner while the service becomes less reliable. The concern routes from Week 10 are part of quality control.

When something goes wrong: service recovery

Service recovery is what the company does after a failure: it stabilizes the situation, communicates, offers a remedy and learns. Miller, Craighead and Karwan (2000) developed a framework that treats recovery as part of process design. Craighead, Karwan and Miller (2004) analyzed a large set of service failures and found that the best recovery depended on how serious the failure was and how loyal the customer was.

So a late message, a wrong public fact, a missed payment and a safety concern should not share one script. For each type, the recovery plan names:

• the first action, and the person with authority to take it;
• the people affected, and what they must be told;
• the limit of the remedy.

Sometimes an apology and a correction are enough. Sometimes the right action is a pause or a safety step. Never promise a remedy the company cannot deliver.

Measuring quality without distorting the work

Managers need to know whether the process keeps its promise, but every measure shifts attention. If staff are judged only on speed, they may skip explaining a change to the performer. If they are judged only on the number of appearances, they may accept an unsafe schedule. So for each measure, state what it can and cannot tell you.

Week 16 will turn such measures into a management dashboard. Until then, keep the protection level out of any average.

What to standardize and what to leave free

A standard operating procedure (SOP) is a written description of how a task is normally done. Standardizing prevents steps from being forgotten and makes training easier. It can also impose the wrong idea of quality and silence local knowledge. So the manager must say exactly what is being standardized, and why.

Adler, Goldoftas and Levine (1999) studied model changeovers at a car plant run on the Toyota Production System. They found that efficiency and flexibility could work together when the plant had metaroutines, which are routines for changing routines.

Here is what that means for a performance team. The warm-up routine is the normal sequence: stretching, a run-through and a safety check. A metaroutine is the agreed way to change that sequence. After each game, the performer, the liaison and Mina spend ten minutes on what to keep and what to change, and one person updates the written plan. The warm-up can improve without anyone quietly dropping the safety check.

Benner and Tushman (2003) argued that strict process management helps in stable work but can hold back more radical innovation. Zollo and Winter (2002) explained that organizations learn by gaining experience, by discussing it and by writing it down, and that the best mix depends on how often a task repeats and how clear its causes are. A first-ever appearance in a new city is rare and unfamiliar. It needs a deliberate discussion afterward, because experience alone will not show what caused success or failure.

These ideas lead to two layers. The protection layer holds conditions that stay the same everywhere: safety, consent, pay, legal duties and the correction of public mistakes. The learning layer holds experiments, such as a new greeting for the fans or a new way to share the schedule. An experiment needs a purpose, an owner, a limit, a review date and a way to stop. Running an experiment never suspends the protection layer.

The four quality levels and the two layers fit together. The levels say what to check, and the layers say what may vary.

Adding local conditions to the blueprint

Week 4 showed how to compare settings by mechanisms, such as who approves and who pays. For operations, the week-specific step is to add a local-conditions note to each stage of the blueprint. For each stage, write what might differ in another place, who knows the local condition, which safeguard stays common and who may approve an adaptation.

For example, an arena in another city may require the performer to arrive two hours before the game instead of one. That changes the call time, and it may affect the 12-hour rest rule. The rest rule stays common, while the arrival time is a local adaptation that the liaison checks with the arena. If nobody knows a stage's local condition, treat that stage as not ready.

Where AI fits in operations

AI tools can draft a brief, compare checklists or suggest a schedule. The operations-specific risk is that a suggested schedule ignores anything that was not in its input, such as the performer's 12-hour rest rule or a local arena rule. So an AI-drafted schedule or brief keeps the status "draft" until the person who owns that stage has checked it against the blueprint. If an output affects pay, safety or consent, a named person must be able to explain the decision without saying that the tool made it.

The three options as operating systems

The blueprint method works for each option, but each creates a different operating risk. The table compares the options on three questions: where the critical process and its bottleneck lie, which protection and recovery test applies, and what evidence is still needed.

The table does not choose an option. It shows which option could run as a manageable system and which would depend on the founder stepping in to rescue it. Before recommending a path, add the missing owner, review date and stop rule for your option.

Class practice: a service blueprint and a capacity check

This practice is done without AI tools. Your teacher will tell you which worksheet to use and how to submit it. Bring your Week 10 protocol.

1. Write the promise and four stages. Choose one service your option would deliver in the next 12 weeks. Write its promise in one sentence, then four stages, each in one line with what the customer sees and the main backstage work.
2. Mark two handoffs. For each, write who passes what to whom.
3. Check capacity. For the scarcest person in the busiest week, write the hours available, the hours needed and the result.
4. Write one protection rule and one experiment. Name a condition that must never vary, and one thing the company could try, with an owner and a review date.

Label every number you invent.

Key points and what you bring to Week 12

• An operation is a chain of promises. Write the promise down, map the actions that keep it, and decide in advance who acts when something goes wrong.
• A service blueprint shows the customer's view and the backstage work on one page. Its handoffs come from the communication protocol.
• Capacity is limited by the scarcest resource in the busiest week. In the worked example, a third team would push test week 7 to 11 of Mina's 10 hours, so on these estimates her time is the bottleneck.
• Check quality at four levels: outcome, process, protection and learning. Protection never varies; the learning layer is where the company experiments.
• Recovery and learning are part of the design. A metaroutine lets staff change a routine without losing its safeguards.

For Week 12. Bring your service blueprint. Week 12 starts from its customer and frontstage rows and asks who pays, who only watches and what each of them values. You will build a customer value table.