Meet the client: Lantern Home
PHASE 0~1 HOUR~7 MIN READREADING ONLYENTRY POINTUNLOCKS 0.2LANTERN HOME DATA
About three thousand times a month, someone writes to Lantern Home with a problem. A parcel that did not arrive. A kettle with a cracked lid. A refund that never came. Those messages land in a shared inbox, and eight support agents open them, one at a time, and figure out what to do.
Right now that process takes about twenty minutes per message when everything goes smoothly, and longer when it does not. With three thousand messages a month and eight people, a customer waits two to three days before anyone reads what they wrote. The goal of this whole course is to change that: software handles the straightforward parts automatically and hands everything else to a person.
Before any program can help, you need to understand what the support team actually does.
The shop and the inbox
Lantern Home sells the ordinary things people need at home: kettles, lamps, bedsheets, cooking pots, phone chargers, school bags. You order on the website and a courier delivers a parcel a few days later. About sixty people work there, and eight of them handle the customer support queue.
When a message arrives, an agent (say James Miller) opens it. He reads it and pulls out the order number, so he can look the order up. He checks the courier's delivery record to see whether the parcel was delivered and when. If the customer says something is damaged, he looks for a photo. He opens the rulebook, a document of twenty rules the team has built up over the years, and works out what the customer is entitled to. He decides: refund, resend, ask for more information, or say no. He writes back. He records his decision.
Reading the message, finding the order, checking the delivery record, looking for a photo if needed, consulting the rulebook, making a decision, writing back, and recording the result: that chain of steps is where the twenty minutes go. If the order number is missing, or the delivery record is vague, or the photo is unclear, it takes longer. And while James is working on one message, the next two have arrived.
Three people, three answers to "what is success?"
Lantern's owner, Sarah Johnson, started the shop and still knows most of the warehouse staff by name. What she wants is simple: a customer with a clear-cut problem should get a correct answer in under an hour, not in three days. She is the one who decides whether to pay for anything you build, so her answer is the one that determines whether the system gets used.
Michael Brown keeps the books. Every refund is money leaving the company, and Michael has to explain each one to the tax office and to Sarah (who paid what, when, what it was based on, and that no record was changed afterwards). A system that pays refunds but cannot show its work is useless to him, no matter how fast it runs.
Rachel Smith runs the support team and wrote most of the rulebook. She wants the rules applied the same way to every customer, regardless of who is on shift. She also knows that some cases are genuinely hard: a customer whose story does not match the records, a photo that could show old damage or new. She does not want any system deciding those on its own. Hard cases should reach her before anything is paid or sent. Easy cases should not need her at all.
Get any one of them wrong and Lantern will not use it. All three have to say yes.
A clear case: Chloe Martin's school bag
Here is a real customer message from Lantern's inbox:
From: chloe.martin@example.com
Received: 2026-09-07 10:05
Subject: return school bag
Hello, I would like to return the school bag from order 48251, my son
does not like the colour. Unused with tags.And here is the row for that order:
| Field | Value |
|---|---|
| Order number | 48251 |
| Customer name | Chloe Martin |
| Item | School bag, blue |
| Item price | 29.90 |
| Order date | 2026-08-31 |
| Delivered | 2026-09-03 |
| Final sale | yes |
The rulebook covers this exactly. Three rules apply:
Rule 1. A customer can report a problem with an order up to 14 days after the delivery date in the courier's record.
Rule 12. A customer who simply no longer wants an item can return it within 14 days, in its original packing, and is refunded the item's price once it arrives back at the warehouse.
Rule 13. Items marked "final sale" on the order cannot be returned for a change of mind. They can still be refunded if damaged or faulty.
The 14-day clock in Rule 1 starts on the delivery date. The parcel arrived on 2026-09-03, and Chloe's message came in on 2026-09-07, four days later, well inside the window. The bag is unused. But the order says final sale: yes, and Rule 13 says final-sale items cannot be returned for a change of mind. Chloe says her son does not like the colour, which is a change of mind. The answer is no.
An agent can reach that conclusion by reading the message, checking the order, and applying the rulebook. There is no ambiguity, no missing information, no judgment call. Chloe's case is a clear case.
A case that reaches Rachel: Grace Thompson's pillowcase
The second message is from Grace Thompson:
From: grace.thompson@example.com
Received: 2026-09-11 21:03
Subject: Order 48285 - one pillowcase missing
Hi, the bedsheet set arrived today but there is only one pillowcase in
the pack and the picture shows two. Not the end of the world but I
would like the second one. Thanks, SofiaAnd here is the order:
| Field | Value |
|---|---|
| Order number | 48285 |
| Customer name | Grace Thompson |
| Item | Bedsheet set, single, blue |
| Item price | 41.00 |
| Order date | 2026-09-03 |
| Delivered | 2026-09-06 |
| Final sale | no |
The order is under Grace Thompson's name, and the message comes from her account. She signs it "Sofia", but support agents work from the account, not the closing name, so this does not change how the case is handled.
The rulebook has sections for items that did not arrive, items that are damaged, wrong items delivered, and changes of mind. A missing item from inside a pack does not fit cleanly into any of them. The parcel was delivered on 2026-09-06, so it is not a lost parcel. But the customer is saying part of what she paid for is simply absent. That could be a packing error in the warehouse, or it could be a misunderstanding of what the product listing showed.
Before anything is sent or refused, this case goes to Rachel. That is what Rule 20 says: if the rules above do not clearly cover the case, or if the agent is unsure for any reason, the case goes to Rachel, and nothing is paid until she decides.
Chloe's case is clear. Grace's case is not. That boundary is the single most important line in the whole project: cases where the rules give a plain answer are handled automatically; cases where they do not go to Rachel before anything is paid or sent.
What gets built, and how
Over this course you will write a program, piece by piece, that handles both sides of that line. It will read a customer message, find the order number inside it, look up the order and the delivery record, check the rulebook, and decide what the customer is entitled to when the rules are clear. When they are not, it passes the case to Rachel with everything she needs to make the call. It records every decision with the message, the order, the rule it applied, the amount if money is involved, who decided, and when.
Phase 1 starts with the smallest working piece of that: a program that reads one message file and pulls out the order number. That is what James Miller does first, every time, for every message. It is a small thing, and it is the foundation.
Unit 0.2 explains how the course is organised and how your work is graded. After that, Unit 0.3 sets up the environment you will need to run Python. Then Phase 1 begins.