The route should not live in one person’s head.

The spreadsheet is a nickname for a person

Someone on the team knows how a piece actually moves. They know which carrier will take a crate of a certain size, which lane is a bad idea in a given season, which destination needs an extra pair of hands, and which “exception” is really a rule that has never been written down. The file they keep is a list of names and rates. The judgment is not in the file. It is in the person who knows which row is a lie this week.

When that person is out, the operation either stops or improvises. A build that starts from the spreadsheet will encode the nicknames and miss the refusals. The next system looks complete and still calls them for the interesting shipments, which were the point.

This note is the TWIMCO Route Knowledge Capture Card. It is the page you fill in an interview with that person, before a routing screen, a carrier integration, or an agent is allowed to suggest a lane. It is not a general catalog of marketplace exception types, and it is not a broad extraction of every judgment in the company. It is logistics knowledge aimed at a later interface: lanes, carriers, handoffs, and the red lines. There is no live form for it on this site. The interview and the card are the asset.

TWIMCO built Paddle8’s fine-art auction house and marketplace, where the sale is not finished when the price exists. A work still has to travel, often with constraints that a generic parcel flow will not respect. Capturing that kind of knowledge is fulfillment and operations work when the goal is a system that can act without pretending the expert is always at the desk.

Do this while the expert is still the expert, not during their last week. A capture done as an exit interview will be shorter than the truth and kinder than the red lines. You want the red lines.

Sit with the person who already decides

One card, one expert session, one shipment family. “Everything we ship” is how the interview becomes a tour. A shipment family is specific enough to argue about: crated works over a certain size, domestic small parcels, cross-border paperwork, local hand delivery. If you do not know the families, the first meeting is only to name them. Do not fill a card for a family you have not named.

Ask them to walk a recent shipment that went well and a recent one that almost did not. Recent means they can point at what they looked up, who they called, and what they refused. Hypothetical routes produce hypothetical rules. The card wants the rule they already used.

Have a second person write, not the expert alone. Experts compress. The writer’s job is to slow the compression down: “When you say we don’t use them for that, is that a preference or a refusal?” Preference can be overridden with a reason. A refusal is a red line. The card has a place for both, and mixing them is how a later builder turns a safety rule into a sort option.

Read the card back before the session ends. The expert corrects the nouns. Carrier names, city pairs, and the words they use for a crate or a courier should be theirs. A cleaned-up paraphrase that they nodded at while tired will be wrong in the way that is hardest to test.

If two experts disagree, do not merge their cards into a smooth average. Keep both, mark the conflict, and name the role who resolves it. An averaged route is a route nobody runs. Resolution might be “it depends on the object,” which is a new field, not a tie.

Store the card where the build team works, dated, with the expert’s name and role, so someone can ask later whether the lane is still real.

Fields the card will not leave blank

The TWIMCO Route Knowledge Capture Card is done only when these lines are filled or explicitly marked unknown. Unknown is allowed. Blank is not, because blank gets treated as “no constraint.”

Shipment family. What this card covers and what it does not. The boundary is part of the knowledge.

Origin and destination patterns. Not every address. The patterns they actually decide on: regions, city types, a building that is always a problem, a border that adds a step. If a pattern is “it depends,” write the dependency.

Carrier or mode options. Who they will use for this family, in the order they actually try, and who they will not. Include courier, freight, and hand carry if those are real options. A rate sheet that lists ten carriers when they only trust two is a different document. Note that difference so the build does not offer eight illusions.

Handoff points. Where the object changes hands: packer, courier, warehouse, building staff, customer. Who is responsible between points. A route that names vehicles and not handoffs will lose the object in the gap the expert currently watches by instinct.

What they look up. The file, the call, the measurement, the photo. If the decision needs a dimension or a value that is not in your system, the card says where it lives today. That missing field is a product requirement, not a detail for later.

Time and cutoff facts. Cutoffs they already live by. Do not invent service levels. Write the ones they treat as real, and mark any that are hopes rather than commitments the carrier has made.

Cost judgment, without fake precision. How they choose when two options both work: cheaper, safer, fewer handoffs, the one who answered. Capture the order of considerations. Do not turn their words into weights.

Failure they expect. The ordinary miss for this family, and what they do next. That next step seeds the exception path, and it should come from them.

Red lines. Separate section, below. If time is short, do the red lines and the shipment family, and mark the rest unknown rather than inventing them after the meeting.

Red lines are not preferences

A red line is a condition under which they will not ship, or will not use a mode, even if someone senior is in a hurry. The card gives each red line a name, a condition you could test, and the reason in the expert’s words. “We don’t like that carrier” is not yet a red line. “We will not hand them an unpacked work” can be, if they mean will not.

Write what they do instead when the red line trips. Stop and call the buyer. Change mode. Repack. Wait for a date. A red line with no alternative is still valid. It means the shipment waits. Say that, so the product does not “help” by picking the forbidden lane when the allowed one is slow.

Mark who may override, if anyone. Some red lines are overridable by a named role with a written reason. Some are not. If the expert says “I would quit before I did that,” believe the structure of the sentence even if you soften the drama: this line has no override on the card. An override added later is a change to the card, dated, not a checkbox a developer adds because the API required a choice.

These contrasts are composites from fulfillment work, not client metrics. A cheap service used only for empty packaging gets offered as a default, because the sheet listed it and the card’s “will not use” line was never filled. A product promises a carrier’s generic transit time when the expert always adds a day for one building. Two people hold two red lines about crates, and the build follows whoever was in the kickoff. Two cards and a named resolver would have kept that conflict visible.

Do not file the red lines in a wiki paragraph under “tribal knowledge.” They sit on the card, in testable conditions, next to the family they govern. A wiki will not fail a pull request. A condition might, if you bother to write the test. That test is the point of capture. Otherwise you have produced a nicer memory.

From the card to an interface

The card is not the system. It is the thing the system has to answer to. When you design the routing step, every option you offer should be traceable to a card: this carrier is in the “will use” list for this family, this option is absent because it is a red line, this field is required because the expert looks it up before choosing. If the interface offers a lane the card does not mention, someone goes back to the expert or explicitly extends the card. Quiet additions are how folklore returns wearing a dropdown.

Bring the expert to the review of the first version. Ask them to run the two shipments from the interview through the screen. Where the screen will not let them follow a red line, the screen is wrong or the card is. Fix one of them in the room. Where the screen asks for a fact they do not have at that moment, you have learned something about timing, not a reason to make the field optional and empty.

An agent that suggests routes is under the same rule. It may propose from the card. It may not invent a forbidden carrier or treat a red line as a preference. If you cannot point the suggestion at the card, do not automate it yet.

Update the card when a carrier changes or an incident teaches a new red line, and have the expert confirm the edit. Put the filled card in the build brief for that family. The live custom product build brief can hold surrounding scope. It does not replace the route card, and it will not interview anyone for you.

Put this into practice

1. Name one shipment family. Book the person who decides its routes. Ask for a shipment that went well and one that almost did not.
2. Fill the TWIMCO Route Knowledge Capture Card with a second person writing. Read it back. Mark conflicts instead of averaging them.
3. Put red lines in testable language, with the alternative and whether anyone may override.
4. Trace the first routing screen or suggestion to the card. Anything the card does not allow does not ship as an option until the card grows on purpose.
5. Scope the operational build under fulfillment and operations. Paddle8 is the picture of commerce that still has to move an object after the number is agreed. The route should survive the day the person who knows it is not in the room.

Knowledge you did not capture will be redesigned by whoever is nearest the keyboard. They are rarely the person who has carried the crate.