All BlueprintsLogistics
Returns handling
The returns desk behind a small shop. A customer asks to send something back and says why, the warehouse answers, a parcel turns up that may not match either, and somebody has to decide what happens to the goods and to the money before either can end up in the wrong place.
What you’ll build.
A returns system. Customers find what they bought, ask to send one thing back and say why, and get an answer with a reason in it. The warehouse books in a parcel that arrived with no paperwork, records what actually came back rather than what was claimed, and either puts it back on the shelf or writes it off. The refund follows the inspection and is never paid twice.
What you’ll learn.
Each sprint is built around one skill. You show you have it in a pull request your team reviews, then explain it in a walkthrough.
Authentication
You can register and sign in a user, keep a request authenticated without asking for the password again, and explain where the credential lives in the browser and why there rather than somewhere else.
An order that moves through states
You can move an order through its states, refuse a transition that should not happen, and show the history of how it got where it is.
Roles and permissions
You can give users different roles and have the server refuse what a role may not do — not merely hide the button — and show the refusal working against a request the interface never offered.
Tracking a delivery
You can record location updates against a shipment and show a customer its current state and history without them refreshing.
Proof of delivery
You can capture proof at the point of delivery, store it against the shipment, and produce it later in a dispute.
Stock that cannot go negative
You can decrement stock on a sale and prove that a hundred simultaneous orders for ten items produce ten sales and ninety refusals.
Going live
Somebody who has never met you can open a URL and use the product — and you can say what is different about the copy running there, where its secrets come from, and what you do when a release turns out to be wrong.
The roadmap. 8 sprints, 40 tasks.
Every sprint has a goal and a set of tasks. Open a sprint to see the tasks you will pick up.
Who is asking, and what they had
A customer signs in and finds the orders they might send something back from, and warehouse accounts cannot be signed up for.
5 tasks
- A customer can register, sign in, and come back to their account
- Delivered orders exist in the product, with what was in them
- A customer sees their own orders and nobody else's
- Warehouse accounts exist, and cannot be self-issued
- Leaving the shared bench terminal ends the session
Asking for one thing back
A customer asks to send back part of an order and says why, and cannot ask for more than they bought or ask twice for the same unit.
5 tasks
- A customer can ask to send back part of an order
- The reason comes from a list, with room for the customer's own words
- Nobody can ask to return more than they bought
- A return is refused after the window, and told which date it was
- A customer can see the returns they have asked for
The other side of the counter
The warehouse works a queue of requests and answers each one with a reason, and nobody can answer their own.
5 tasks
- The warehouse has a queue of requests waiting for an answer
- An approved return tells the customer what to send and where
- A declined return gives the customer a reason they can read
- Nobody can answer their own return, or read anybody else's
- Part of a request can be approved and the rest declined
The parcel nobody announced
A parcel on the bench is matched to the return it belongs to even with no paperwork, and an approved return that never arrives stops waiting.
5 tasks
- The warehouse books in a parcel against the reference it carries
- A parcel with no paperwork can be matched by searching for the order
- A parcel nobody can match is held rather than guessed at
- An approved return that never arrives closes itself
- The warehouse can see what it is still waiting for
What actually came back
Somebody at the bench records what is really in the parcel, with evidence, and any disagreement with the customer's reason is kept rather than overwritten.
5 tasks
- An inspection records what was actually in the parcel
- Every returned item gets a condition recorded against it
- An inspection knows which of its photographs never arrived
- Where the bench disagrees with the customer, both are kept
- The customer can see what was received and in what state
Shelf or write-off
Every inspected unit goes back into sellable stock or is written off with its cost recorded, exactly once, by somebody named.
5 tasks
- Each item has a count of what is on the shelf
- A returned unit goes back on the shelf only after it has been inspected
- A written-off unit records what it cost and why
- The same unit cannot be dealt with twice
- The shop can see what came back this week and what it was worth
Paying it back once
The refund follows the goods decision, is for what was paid for what came back, and the same money is never paid twice.
5 tasks
- A refund is raised only once the goods have been dealt with
- The refund is for what was paid for what actually came back
- Pressing refund twice pays once
- A return settled while the whole order is refunded pays out once
- Nobody waits a month for their money
Somewhere a customer can reach
The product runs on the internet at its own address, keeps its evidence, and a bad release can be undone without losing returns that were in flight.
5 tasks
- A stranger can open the URL and use the returns desk
- Every value the product needs comes from its environment
- The inspection photographs survive a deploy
- A release that turns out to be wrong can be undone
- Somebody other than the author can tell whether it is working
Read before you build. The best engineers do.
Senior engineers read the docs before they touch the code. Every Blueprint comes with short documents on the product and its world, the kind a team hands a new hire. Read them well and you ask sharper questions and walk into every review prepared.
What you are building
The product, the two people who use it, and why a return is not an order played in reverse.
How a returns desk actually works
Domain you will not have: authorisation, goods-in, disposition, credit, and why returns frighten the people who run shops.
More logistics Blueprints.
Tool and asset checkout
A tool store for a small builder's yard. Every drill, ladder and transformer is an individual thing with a tag, the store can say who is holding it and since when, and what has not come back is on one screen before somebody needs it.
Fleet maintenance log
A servicing log for a small fleet: every van's history in one place, the next service worked out from how fast that van is actually being driven, and what is due soon and what is already overdue on the front page.
Warehouse picking list
Picking for one warehouse: an order becomes a route through the shelves, a picker walks it on a handheld, and everything that goes wrong halfway down the list is recorded rather than quietly shipped.
Build returns handling.
Start your free week. Adaeze runs your kickoff, and Lars reviews every pull request.