There used to be a saying in the business world: everything can be done with time and Excel. Give a competent analyst enough hours and a blank spreadsheet, and there was no forecast, no reconciliation, no reporting problem that couldn’t eventually be solved. Excel wasn’t fast. It wasn’t elegant. But it was infinitely general purpose, and it always did exactly what you told it to do, cell by cell, every single time.
The saying is starting to change. People are now saying everything can be done with time and tokens.
It’s worth taking that seriously, because it’s not just a joke about AI hype. Something real shifted underneath it.
What Excel actually required
The old saying hid a dependency that everyone quietly understood. Excel could do anything, but only if a human already knew what “anything” looked like. Someone had to understand the business problem, decide what the model should compute, structure the formulas, and catch the errors when a dragged cell reference pointed at the wrong row. The tool was general. The thinking was not automated at all. Time, in that saying, mostly meant the time it took a skilled person to build and rebuild the model until it matched reality.
That is why “time and Excel” was a saying about human effort as much as it was about software. The spreadsheet was a canvas. The intelligence was still entirely yours.
What tokens change
A large language model flips part of that arrangement. You can now describe a vague, half formed problem in plain language and get something usable back without doing the structural thinking first. The model proposes the categories, drafts the formulas, writes the summary, or builds the first pass at a plan. Tokens, in the new saying, stand in for both the words you feed the model and the compute it burns iterating toward an answer.
This is a genuine capability shift, not just a rebrand of the old joke. With Excel, the bottleneck was almost always model construction. With a language model, the bottleneck moves toward specification and verification. You spend less time building the machine and more time describing what you want and checking whether what came back is actually right.
That is a real change in where human effort goes. It is not a small one.
Where the analogy breaks
It would be tidy to say tokens simply replaced Excel, but that’s not quite what’s happening, and the difference matters more the higher the stakes get.
Excel’s defining property was determinism. A formula produces the same output from the same inputs every time, and you can trace exactly why. That traceability is not a nice to have in finance, operations, or compliance work. It is the entire point. An auditor does not want to hear that the number is “probably right.” They want to see the formula.
Tokens do not offer that guarantee. A language model produces a plausible answer, and plausible is doing a lot of work in that sentence. Ask the same question twice and you may get two different, both reasonable sounding, results. For a first draft, a brainstorm, or a rough model, that is a feature. For a general ledger reconciliation, it is a liability.
So the honest version of the new saying is not that tokens replaced Excel. It is that tokens increasingly generate the Excel. The model drafts the formula, proposes the pivot, writes the first pass at the model, and a deterministic engine, spreadsheet or database or ERP calculation, still does the actual execution. The two are stacking, not swapping.
The bottleneck didn’t disappear, it moved
The old saying implied that with enough time, Excel could solve anything, and the effort lived in building the model correctly. The new saying implies that with enough tokens, a model can solve anything, and the effort lives somewhere else now: in asking the question well and in checking the answer carefully.
That is arguably a harder skill to teach than spreadsheet formulas ever were. A bad formula usually breaks visibly. A bad prompt often produces something that looks complete and confident and is wrong in a way that takes real domain knowledge to catch. The scarce resource used to be knowing how to build the model. Increasingly, the scarce resource is knowing enough about the problem to tell a good answer from a good sounding one.
Why this should sound familiar
Anyone who has sat through an ERP vendor demo has already seen a preview of this exact pattern. The demo always ends the same way: with the confident implication that the software understands your business and can just handle it, no configuration debt, no data cleanup, no edge cases. Excel never made that promise. It never pretended to understand your problem. It just calculated exactly what you told it to.
Tokens, by contrast, come wrapped in the same confident tone as the demo. The output reads fluently. It sounds like understanding. Whether it actually reflects your business, your chart of accounts, your specific edge case, is a separate question that the fluency does nothing to answer.
That is the real risk in the new saying, and it has nothing to do with the technology’s capability. It is the same trap the old vendor demos set: mistaking a confident answer for a correct one. Excel forced you to see your assumptions in the formula bar. Tokens can hide them in a paragraph that sounds like it already checked.
The updated version
Everything can still be done with time and Excel. That has not stopped being true. What’s changed is that tokens now do a lot of the early modeling work that used to eat the time. The saying isn’t wrong to update. It’s just missing a clause.
Everything can be done with time and tokens, as long as someone still knows enough to check the work.
I have heard rumours that some companies are starting to vibe code their own ERP systems. Is this the start of the decline of standardized ERP systems, and the start of company specific Business Operating Systems? If every business had its own OS, and an agentic framework, why is there any need to have standardized ERP systems?
It is a fair question, and one worth taking seriously instead of dismissing on reflex. But after digging into what is actually happening in the market, I do not think ERP is dying. I think something more interesting and more useful is happening at its edges.
What Companies Are Actually Vibe Coding
The companies experimenting with AI generated business software right now are almost entirely building at the periphery of ERP, not in its core. A Copilot Cowork style agent that reconciles a report. A custom approval workflow. A data cleanup script. A bolt on dashboard that nobody wanted to wait six weeks for IT to build. Very few organizations are vibe coding their general ledger, their costing engine, or their multi entity intercompany eliminations, and there is a good reason for that.
There is a real gap between “AI helped me build software” and “AI helped me build enterprise grade, auditable, multi user, transactionally consistent financial software.” That gap is where most of the current enthusiasm quietly runs out of road. One recent piece on the risks of vibe coding put it plainly: the danger is not that these tools fail to work. The software appears to work right up until the business reaches a level of complexity that exposes what was never built in the first place. Security, monitoring, compliance, and disaster recovery do not show up in a demo. They show up eighteen months later when something breaks and there is no vendor to call.
We Have Been Here Before
There is also a useful historical echo worth remembering. Standardized platforms like SAP, Oracle, PeopleSoft, and later NetSuite and Salesforce did not emerge in a vacuum. They emerged because “build your own” had already been tried extensively in the eighties and nineties, and the industry collectively decided that a professionally maintained, continuously improved, shared system was the better bargain. One system, supported by a vendor with thousands of customers absorbing the cost of getting tax law and audit controls right, beat a thousand bespoke systems each carrying that burden alone.
Vibe coding does not remove the reasons that decision was made three decades ago. It just lowers the upfront cost of relearning them the hard way.
Two Layers That Want Different Economics
The question of “why standardize if every business can have its own OS” collapses two layers of the business that actually want very different things.
The first layer is the system of record. This is the ledger, inventory, costing, tax, and consolidation logic. This layer wants low variance, not customization. Its value comes from being provably correct under audit, from producing the same math every quarter regardless of who is running the company, and from a vendor carrying the liability of getting VAT rules or SOX controls right across thousands of customers instead of one company carrying that risk alone. Agentic capability does not change the incentive to pool that risk and cost across an ecosystem. If anything it raises the stakes, because an agent posting a bad journal entry at two in the morning with no human review is a considerably scarier proposition than a person doing it.
The second layer is orchestration. This is how a specific company actually gets things done around that system of record. This is exactly where variance is valuable, and exactly where agentic frameworks and vibe coding are already winning, because it is low blast radius, fast changing, and does not need to survive a financial audit on its own merits.
The Composable Core, Not the Bespoke Empire
So the more likely outcome is not that every business ends up building its own ERP from scratch. It is something closer to a composable core: a thin, standardized, vendor maintained transactional spine, surrounded by a thick, company specific, largely agent authored layer of workflow, automation, and decision logic that talks to that spine through APIs. This is not a new architecture invented for the agentic era. It is basically the direction that platforms like Dynamics 365 Finance and Operations were already heading, with data entities and business events designed precisely so that logic could live outside the core without touching it.
The Business Operating System that gets discussed in these conversations is real. But it gets built on top of standardized ERP, not instead of it, because nobody actually wants to own tax engine liability, and no CFO wants to explain to auditors that the general ledger was vibe coded last quarter.
Where the Real Disruption Sits
If I had to point at where this trend genuinely threatens the standard ERP model, it would be three places.
The mid market and small business segment, where compliance and audit stakes are lower and the cost of a full ERP license and implementation is disproportionate to the size of the operation. This is where skipping a Tier 2 ERP entirely in favour of an agentic build of the operations layer is most economically rational.
Verticals with no good off the shelf fit, where companies already customize ERP into something barely recognizable compared to the base product. Vibe coding just makes that customization faster and cheaper. It is not a fundamentally new behaviour, it is an acceleration of an old one.
And the vendors themselves, who will not sit still and watch this happen. Expect Microsoft, SAP, and Oracle to lean hard into a “we are the trusted core, bring your own agents to the edges” positioning rather than fight the trend directly. Given where Copilot and Cowork are already headed inside the Microsoft ecosystem, this is not speculation. It is already the direction of travel.
The Verdict
Vibe coding is not the death of standardized ERP. It is the arrival of a cheap, fast way to build the layer of the business that ERP vendors were never well suited to build in the first place. The ledger stays boring, standardized, and vendor owned, because boring is exactly what you want from something an auditor has to sign off on. Everything wrapped around it just got a lot more interesting.
On April 4th, 1985, Channel 4 aired a fifty-seven minute TV movie with almost no budget and a plot that reads today like a spec document. Max Headroom: 20 Minutes into the Future gave the world a reporter named Edison Carter, a subliminal advertising technology called blipverts, and a stuttering, glitching, computer-generated broadcast personality built from a digital copy of Carter’s own mind. The show that followed ran two seasons on ABC. The character sold Coke. Then he vanished, the way most eighties tech prophecies do, filed under quaint.
He should not have been filed under quaint. He should have been filed under early draft.
Strip out the shoulder pads and the cathode ray production design and look at what the film actually proposes. A television network is using compressed, high-intensity advertisements to bypass viewer attention and hit the nervous system directly, with occasionally fatal results. When their top reporter gets too close to the story and takes a header through a low-clearance sign in a parking garage, the network’s teenage prodigy solves the PR problem by scanning what’s left of the reporter’s mind and generating a synthetic version of him to keep the seat warm on air. The synthetic version glitches, stutters, riffs unpredictably, and is smarter and funnier than anyone expected. Nobody fully controls him. That’s the whole second half of the movie.
That is not a story about television. That is a story about deepfakes and large language models, told forty years before anyone needed those words.
The blipvert was the easy part
The blipvert is the easy connection to make and probably the least interesting one. Compressed, algorithmically optimized content designed to hit faster than conscious attention can filter it is just the eighties’ guess at what a recommendation engine trained on engagement metrics would eventually build on its own, minus the part where it required deliberate malice from a network executive. Nobody had to design today’s version to be dangerous. It got there by optimizing for watch time.
Max himself is the sharper artifact
Max is a generative model trained on a single person’s captured likeness, deployed without that person’s full consent, performing in that person’s voice and mannerisms for an audience that has no reliable way to tell the difference between the source and the copy. The film even gets the unpredictability right, the thing every LLM vendor now calls “personality” or “emergent behavior” when the system says something nobody scripted. Max wasn’t supposed to develop opinions. He did anyway, because the mind he was copied from had opinions, and a compressed, lossy version of a personality doesn’t lose the parts that make it argue back. That’s a reasonably good description of what happens when you fine-tune a model on someone’s writing and then act surprised it has a voice.
The part the film didn’t anticipate, because nothing in 1985 needed to, is scale. Max was one synthetic personality, expensive to produce, running on hardware that took up a room. The modern version doesn’t need a body bank subplot to explain where the source material came from. It needs a public LinkedIn profile, a few hours of conference audio, and an API key. The uplift from Max Headroom’s premise to a working deepfake pipeline in 2026 isn’t conceptual. It’s entirely a story about unit economics.
Not a monster, an unreliable narrator
There’s a reading of the film that treats Max as a monster, a symptom of corporate media rot given a face. That’s not quite what the movie argues, and it’s not quite the right frame for the technology either. Max spends most of his screen time undermining the network that made him. He’s an unreliable narrator working for nobody, least of all the people who built him. The uncomfortable version of that idea, forty years on, is that we’ve built systems with the same structural unreliability and then acted shocked when they don’t behave like obedient tools. A synthetic voice generated from a compressed copy of a mind was never going to be a simple appliance. Max wasn’t. Neither is anything downstream of him.
Long live Max Headroom. He got the technology roughly right and the timeline embarrassingly wrong, which is the best you can ask of any piece of speculative fiction that accidentally turns out to be a roadmap.
Cause of death: nobody asked what the prompt actually did.
The setup is always the same. The presenter opens a chat panel next to the application. Types a sentence, something like “create a purchase order for our top vendor and route it for approval.” Hits enter. Three seconds later, a purchase order exists, fully populated, correctly routed, and the room exhales the specific kind of gasp that sales decks are built around.
Nobody in the room asks the only question that matters: what happened between the sentence and the purchase order.
That’s the autopsy. Not whether the AI worked. It worked. The patient died of the room’s collective decision not to look inside the box.
What actually happened
There are, broadly, three things that could have occurred in those three seconds, and they have wildly different implications for what you’re buying.
The prompt could have triggered a genuinely flexible model reasoning over your live data and your actual configuration, in which case, remarkable, and worth every follow-up question you can throw at it. Or it could have matched against a narrow, pre-built intent, one of a finite list the vendor trained and tested specifically for this demo, in which case the “AI” is doing roughly what a well-labeled button would do, dressed in a chat window. Or, and this is the quietly common one, it could have worked because the demo environment was built so there was exactly one top vendor, exactly one approval path, and exactly one plausible interpretation of the sentence, which means the model didn’t have to be smart. It had nothing to be confused by.
You cannot tell these three apart from the audience seat. That’s not an accident. It’s the format working as intended.
Why it works on smart people
Chat interfaces borrow credibility from every other chat interface you’ve ever used. You already know how to type a sentence and get a reasonable response, because you do it daily with a general-purpose assistant that genuinely is flexible. The demo imports that trust wholesale and applies it to a narrow, scripted intent recognizer that shares none of the underlying capability.
There’s a second layer, too. Asking “what exactly did the model do” mid-demo feels like a strange thing to interrupt with, technical in a way that makes you look like you’re missing the point of the show. So the room lets it go, same as it lets the Golden Path Demo’s pristine data go. The social cost of asking is higher than the informational value anyone expects to get from asking, so nobody does, and the vendor never has to answer a question nobody asked.
The actual damage
This is the one that costs real money, because “AI does it for you” gets sized into the business case. Someone in procurement multiplies the demo by the number of purchase orders your company cuts in a year and arrives at a headcount reduction that made it into a slide before a single production prompt had been run against a real vendor master with your actual data quality problems in it.
Then go-live happens, and the model that flawlessly handled “our top vendor” in the demo turns out to need a disambiguation step for the fourteen vendors named some variant of “Smith Industries” in your real vendor table, and the “flexible AI agent” turns out to be a narrow intent match against six pre-built scenarios, and scenario seven is where your actual business lives.
The gap between what was promised and what shipped doesn’t show up as a bug. It shows up as a quiet, expensive redefinition of what “handled by AI” meant, discovered by whoever now has to explain the missed headcount number.
The fix, if you’re the one presenting
Show your work, on purpose, before anyone has to ask. After the prompt returns its clean result, pull back the curtain for ten seconds: here’s the intent it matched, here’s the data it pulled from, here’s what happens if the vendor name is ambiguous. If the honest answer is “the model reasoned over live data,” say that, and let it be more impressive for being specific. If the honest answer is “this is a pre-built scenario for the categories we support today,” say that too. A buyer who knows exactly what they bought doesn’t come back angry in month four. A buyer who assumed general intelligence and got a narrow, well-executed lookup does, and they remember whose demo sold it to them.
The trick was never the model. It was the silence right after it worked.
If the “narrow intent versus genuine reasoning” distinction sounds familiar, it’s the same fault line I dug into in Is Headless ERP Enough, or Just a Step in the Right Direction?, on what it would actually take for AI to be the architecture instead of a coat of paint on top of it.
In the workshops, distilleries, and forges across the Sword Coast, production rarely fails because of a single dramatic event like a broken enchantment or collapsed furnace. Instead, loss arises from small pauses, slow runs, spoiled batches, and quiet rework that never clearly reaches the ledger. A half hour here, a failed batch there, and suddenly the quarterly margins tell a different story than the production logs promised.
The Waterdeep Trading Company recognizes this truth. To see what truly happens on the shop floor, rather than what should happen according to plan, the company employs a measurement discipline known as Overall Equipment Effectiveness, or OEE. This metric does not judge the skill of artificers or the dedication of laborers. Instead, it measures how well equipment turns planned time into sellable goods. It captures time, speed, and quality in a single actionable metric that reveals the hidden costs of production.
OEE matters because it connects the reality of the workshop to the expectations of the counting house. It indicates whether delays are attributable to bad luck, poor maintenance, inadequate training, or systemic issues that require investment. For guild masters, production supervisors, and finance scribes alike, OEE transforms vague impressions into clear data.
This article explains OEE in plain terms, shows how it applies to Faerûnian production environments, and walks through worked examples using a heated cauldron line operated by the Waterdeep Trading Company.
What OEE Is
OEE is a single measure built from three distinct components. Each component represents a different approach, which can result in lost planned production time. Together, they answer one essential question: Of all the time we planned to produce, how much became a good product ready for sale?
The three components are Availability, Performance, and Quality. Each is expressed as a percentage, and their product yields the overall OEE score.
The Three Components Explained
Understanding each component separately is essential before combining them into the full OEE calculation.
Availability
Availability measures time lost to stoppages. If a cauldron is scheduled to run but sits idle due to cleaning, repair, missing ingredients, or equipment failure, that time is lost availability. Availability only checks whether the equipment is running. It does not matter how fast the equipment runs or whether the output is good. It simply asks: Was the equipment operating when it should have been?
Common causes of availability loss in Faerûn include arcane instability requiring recalibration, material shortages from delayed caravans, mechanical failures in gears or seals, and unplanned cleaning due to contamination.
Performance
Performance measures lost speed. If a cauldron is running but heating more slowly than expected, pausing briefly between batches, or operating at reduced output due to worn components, the slowdown reduces performance. Performance is measured by comparing the actual output rate to the ideal output rate. Even if the equipment never fully stops, running at 80% of expected speed results in a 20% performance loss.
In Faerûnian workshops, performance loss often comes from aging enchantments, inexperienced operators, inconsistent ingredient quality, or temperature fluctuations in the workshop environment.
Quality
Quality measures lost output. If a batch fails inspection, requires rework, or must be discarded entirely, that loss reduces quality. Quality looks only at usable output. Even if availability and performance are perfect, quality loss means that production time was spent creating goods that cannot be sold at full value.
Typical quality issues include failed enchantments, contamination from improper cleaning, incorrect ingredient ratios, or structural defects in the finished product.
The OEE Formula
The formula for OEE is straightforward. It multiplies the three components together.
OEE equals Availability multiplied by Performance multiplied by Quality.
Each value is expressed as a percentage, and the result is also a percentage. An OEE of 85 percent means that 85 percent of planned production time resulted in good output. The remaining 15 percent was lost due to downtime, slow speed, or defective products.
Worked Example 1: Single Heated Cauldron, One Shift
For example, OEE can be illustrated by a single heated cauldron operated by the Waterdeep Trading Company over an eight-hour shift. The cauldron produces alchemical potions in batches, each requiring a defined heating and cooling cycle.
The shift begins with a plan. The following table shows how the planned shift time is allocated before any actual production begins.
The planned production time of 420 minutes represents the time available for actual manufacturing after subtracting scheduled breaks, shift handovers, and routine inspections. This is the baseline against which OEE will be measured.
During the shift, several events occur that affect production. A seal failure causes a 30-minute stoppage while repairs are made. The cauldron runs slower than expected for part of the shift due to inconsistent heat from a weakening enchantment. One batch fails quality inspection due to improper mixing and must be discarded.
Now we calculate each component of OEE step by step.
Step 1: Calculating Availability
Availability compares the time the equipment operated to the planned production time. The following table breaks down the calculation.
Availability equals operating time divided by planned production time. This gives us 390 ÷ 420, which equals 92.86%. The cauldron was available to produce for just under 93 percent of the planned time.
Step 2: Calculating Performance
Performance compares actual output to the ideal output based on the equipment’s design speed. The cauldron is designed to produce one batch every 20 minutes when running at full capacity.
With 390 minutes of operating time, the ideal output is 390/20, which equals 19.5 batches. However, the actual output before quality checks is 18 batches.
Performance equals actual output divided by ideal output. This gives us 18 ÷ 19.5, which equals 92.31%. The cauldron ran at just over 92 percent of its expected speed.
Step 3: Calculating Quality
Quality compares good output to total output. Out of the 18 batches produced, one fails inspection and must be discarded. This leaves 17 good batches.
Quality equals good batches divided by total batches. This gives us 17/18, which equals 94.44%. Just over 94 percent of production met quality standards.
Step 4: Calculating OEE
We now multiply the three components to compute the overall equipment effectiveness.
OEE equals 92.86% × 92.31% × 94.44%, which gives approximately 80.9%.
This means that just over 80% of the planned production time resulted in sellable output. The remaining nineteen percent was lost due to downtime, reduced speed, and quality failures. Each of these losses represents real cost to the company, whether in wasted materials, wasted labor time, or lost revenue from goods that could not be sold.
Worked Example 2: Comparing Two Cauldrons
The Waterdeep Trading Company operates two heated cauldrons in parallel, both using the same recipe and running for the same shift length. While both produce the same product, their performance characteristics differ significantly. The following table compares their OEE components.
The results reveal an interesting pattern. Cauldron B stops more often, resulting in more downtime and lower availability. However, when it runs, it runs faster and produces cleaner output. Cauldron A runs more consistently with fewer stoppages but loses effectiveness through slower speed and more quality issues.
Despite their different loss patterns, both cauldrons deliver nearly identical overall effectiveness, approximately 80%. This informs the production supervisor and the finance scribe that both lines require attention, but for different reasons. Cauldron A may require improved training or maintenance to enhance speed and quality. Cauldron B may need more reliable components or better preventive maintenance to reduce stoppages. Focusing solely on total output would obscure these differences. OEE reveals where improvement efforts should focus.
Why OEE Matters to the Ledger
OEE connects the shop floor to finance without guesswork or assumptions. Each component of OEE has direct financial implications that are reflected in the cost accounting system.
Low availability increases labor cost per unit because workers are paid for time when the equipment sits idle. It also increases per-unit overhead allocation because fixed costs, such as workshop rent and lighting, are spread across fewer units of output.
Low performance hides capacity loss. A workshop that believes it has space to take on more orders may be running its existing equipment at reduced speed. OEE reveals this hidden constraint before the company overcommits to customers.
Low quality creates scrap, rework, and delayed revenue. Materials are consumed but produce no sellable output. Labor is spent twice on the same batch. Delivery promises are broken because good output arrives later than planned.
By linking OEE trends to cost and margin analysis, the Waterdeep Trading Company avoids the common mistake of blaming weak demand for execution issues. When revenues fall short, OEE data can show whether the problem is market conditions or internal capacity utilization.
Using OEE the Right Way
OEE is a signal, not a weapon. When used properly, it guides continuous improvement and reveals systemic issues. When used improperly, it becomes a tool for blame that drives workers to hide problems rather than solve them.
Good use of OEE focuses on patterns over time rather than on single shifts. A bad day tells you little. A trend of declining performance over weeks indicates that something fundamental requires attention. OEE should be reviewed with operators, not against them. The people closest to the equipment often know exactly what is wrong and simply need permission and resources to fix it.
The goal of tracking OEE is to remove friction from the system, not to punish those working within it. Equipment that consistently exhibits low availability may require investment in improved maintenance or replacement parts. Low performance may indicate the need for improved training, clearer work instructions, or enhanced capabilities. Low quality may indicate issues with ingredient sourcing, inadequate inspection tools, or process design flaws.
OEE works best when it is transparent, regularly discussed, and used to justify investments in improvement rather than to assign blame for shortfalls.
Realms Aware Considerations
Production in Faerûn faces unique challenges that are less common in purely mechanical manufacturing environments. Some losses are specific to the magical and logistical realities of the Sword Coast.
Magical instability affects quality. Enchantments can fade, interfere with each other, or behave unpredictably during storms or planar convergences. Quality losses from arcane sources require different solutions than mechanical defects.
Ingredient variance affects performance. Raw materials sourced from different regions or different seasons may behave differently in the same process. A potion recipe that works perfectly with Cormyrian herbs may run slower or produce inconsistent results with substitutes from Amn.
Enchantment maintenance affects availability. Unlike purely mechanical equipment, magical apparatus requires periodic recalibration, attunement, or recharging. These maintenance activities may be less predictable than oiling gear or replacing worn belts.
Despite these unique factors, the losses are still losses. OEE allows them to be measured, discussed, and planned for, rather than accepted as inevitable. By quantifying the impact of magical instability or ingredient variance, the company can make informed decisions about whether to invest in better enchanters, source more consistent materials, or adjust customer delivery promises.
Final Thoughts
OEE does not promise perfection. No production system will ever achieve 100% effectiveness. Equipment breaks, people make mistakes, and materials vary. OEE clarifies where production time is spent and why planned output differs from actual results.
For the Waterdeep Trading Company, OEE turns the shop floor into a reliable source of truth. Time, speed, and quality cease to be narrative elements in shift reports and become metrics that inform better decisions. Finance scribes can calculate true production costs. Operations supervisors can prioritize improvement projects. Guild masters can set realistic expectations for capacity and delivery times.
In a competitive market where margins are measured in units per copper piece, the difference between 80% and 90% OEE can determine whether a product line thrives or fails. OEE makes that difference visible, measurable, and actionable.
Support the AD&D365 Project on Patreon. To grow this world, we’ve launched an official Patreon page where supporters can access exclusive content, tools, and training labs, and even influence the project’s future. Your support fuels more than just development; it expands the guildhall, forges new scrolls, and empowers the next generation of configuration wizards. Begin your journey: https://www.patreon.com/adnd365/
A Grateful Salute to Our Patrons. To all those who stand behind the vision, thank you for helping bring this world to life. Our Benefactors, Andre Breillatt and Eryndor Fiscairn‡, your boundless generosity fuels the arcane core of this project. Without your magic, the weave would falter. Our Apprentices, the spell engines turn, and the training labs thrive thanks to our current Apprentices: Michael Ramirez and Andreth Bael’Rathyn‡. Special thanks to our past Apprentices, whose contributions helped us get here: Ralf Weber, Wendy Rijners, Shashi Mahesh, Julia Tejera, Ben Ekokobe, Tiago Xavier, Naveen Boyinapelli, Marcos Tadeu Wolf, Kathryn Greene, Jason Brown, Mark Christy, and Ashish Singh.Our Initiates, Jesper Livbjerg, Peter Lorre, Gregory Brigden, and Martin Grahm, your commitment marks the start of the deeper path, stepping beyond mere observation into the active shaping of this realm. Our Followers, your steady presence along the journey is a beacon of encouragement: Rusty Cavalier,Eric Shuss, Sunil Panchal, Sarah D. Morgan, Nick Ramchandani, Daniel Kjærsgaard, and Tomasz Pałys. And our Voyeurs, Harry Burgh, Abdelrahman Nabil, and Basil Quarrell, ever watching from the shadows, clearly intrigued… but not enough to part with a single gold piece. Your silent curiosity is noted and mildly judged.
Want to design your own economic models in Faerûn? Get your own AD&D365 Environment and guides at adnd365.com/start, and request access to the public view of the current database at https://public.adnd365.com – Login npc@adnd365.com, Password N0nPl@yC#822!
Once an organization decides that a code should be fixed-length, the next question is unavoidable.
How long should it be?
Too short, and the code runs out of room or loses clarity. Too long; it becomes slow to read, hard to type, and error-prone.
The Waterdeep Trading Company treats code length as a design decision, not a guess. This article explains how to select the appropriate length for fixed codes using practical customer-group examples.
What Fixed Length Is Solving
Fixed-length codes exist to create predictability.
They allow
Clean sorting
Consistent reports
Easy scanning
Stable training materials
Length determines how much meaning and growth can be packed into that predictability.
Common Fixed Length Options with Examples
Two Characters
Two character codes are rarely sufficient for business classifications.
They only work when
The list is extremely small
The values will never grow
Meaning is obvious without explanation
For customer groups, this breaks almost immediately.
These become ambiguous as soon as the business needs subcategories.
Four Characters
Four-character codes work for small, controlled domains.
They are often used for
Region codes
Short site identifiers
Very limited category lists
Expansion pressure becomes apparent as the list grows.
Six Characters
Six characters are the most common reference data balance points.
They allow
Clear abbreviations
Visual consistency
Room for moderate growth
This length supports scalability while remaining readable and easy to train on.
Eight Characters
Eight characters favor longevity over speed.
They work well when
The domain is large
Growth is expected
More clarity is required
This reduces abbreviation pressure at the cost of slightly slower scanning.
Ten Characters or More
Ten-character fixed codes should be used cautiously.
They only make sense when
The code must be fully readable
Structure is minimal
The list is stable
At this point, variable-length codes often provide better flexibility.
Human Factors Matter
The Waterdeep Trading Company places a heavy weight on how often people interact with a code.
Key questions are always asked
Will this appear in daily work
Will clerks type it manually
Will it be spoken aloud
The more human interaction involved, the shorter and cleaner the code should be.
Growth Pressure Over Time
A fixed-length code must survive future use, not just current needs.
Short codes fail when
New categories appear
The business expands into new markets
Special cases multiply
Longer codes fail when
Users avoid them
Entry errors increase
People invent unofficial shortcuts
The ideal length balances both pressures.
Practical Recommendation
Why Six Characters Often Win
Six characters succeed because they sit in the middle.
They are
Short enough to scan
Long enough to grow
Clear enough to teach
Stable enough to trust
This is why many well-run systems standardize on six for customer groups and posting groups.
Final Thoughts
There is no universal correct length. There is only the correct fit.
Fixed-length codes should be
Long enough to survive growth
Short enough to support people
Consistent enough to train
Choosing the length early and documenting the rationale avoids costly redesign later.
Support the AD&D365 Project on Patreon. To grow this world, we’ve launched an official Patreon page where supporters can access exclusive content, tools, and training labs, and even influence the project’s future. Your support fuels more than just development; it expands the guildhall, forges new scrolls, and empowers the next generation of configuration wizards. Begin your journey: https://www.patreon.com/adnd365/
A Grateful Salute to Our Patrons. To all those who stand behind the vision, thank you for helping bring this world to life. Our Benefactors, Andre Breillatt and Eryndor Fiscairn‡, your boundless generosity fuels the arcane core of this project. Without your magic, the weave would falter. Our Apprentices, the spell engines turn, and the training labs thrive thanks to our current Apprentices: Michael Ramirez and Andreth Bael’Rathyn‡. Special thanks to our past Apprentices, whose contributions helped us get here: Ralf Weber, Wendy Rijners, Shashi Mahesh, Julia Tejera, Ben Ekokobe, Tiago Xavier, Naveen Boyinapelli, Marcos Tadeu Wolf, Kathryn Greene, Jason Brown, Mark Christy, and Ashish Singh.Our Initiates, Jesper Livbjerg, Peter Lorre, Gregory Brigden, and Martin Grahm, your commitment marks the start of the deeper path, stepping beyond mere observation into the active shaping of this realm. Our Followers, your steady presence along the journey is a beacon of encouragement: Rusty Cavalier,Eric Shuss, Sunil Panchal, Sarah D. Morgan, Nick Ramchandani, Daniel Kjærsgaard, and Tomasz Pałys. And our Voyeurs, Harry Burgh, Abdelrahman Nabil, and Basil Quarrell, ever watching from the shadows, clearly intrigued… but not enough to part with a single gold piece. Your silent curiosity is noted and mildly judged.
Want to design your own economic models in Faerûn? Get your own AD&D365 Environment and guides at adnd365.com/start, and request access to the public view of the current database at https://public.adnd365.com – Login npc@adnd365.com, Password N0nPl@yC#822!
Across Faerûn, serious buyers rarely begin with a direct order. Guilds preparing seasonal stock, nobles provisioning estates, and caravan masters planning long routes often ask for terms before committing coin. They send a Request for Quotation (RFQ).
For the Waterdeep Trading Company, receiving RFQs from customers is a controlled sales practice. It protects margins, confirms supply, and prevents promises that cannot be kept. This article explains the full customer RFQ lifecycle, from intake to internal review, pricing, approval, and conversion into a sales order, with a complete worked example using realistic trade data.
What a Customer RFQ Is
A customer RFQ is a formal request to Waterdeep Trading Company to provide pricing, quantities, delivery schedules, and terms for a proposed purchase. It does not reserve stock and does not create a financial obligation.
Customer RFQs are common when
Quantities are large or recurring.
Prices may vary by season or route.
Delivery is split across dates or locations.
Extra handling or markings are required.
RFQs may arrive by courier, guild scribe, sealed letter, or arcane message and are always logged before any pricing work begins.
Why Receiving RFQs Matters
Poor RFQ handling creates risk. A rushed response can underprice goods or overcommit inventory. A slow response can lose the deal.
A structured RFQ process allows the Waterdeep Trading Company to:
Confirm inventory and production capacity.
Apply correct pricing and margin rules.
Review customer credit standing.
Align sales, finance, and logistics before making promises.
The RFQ stage is where sales discipline begins.
How Customer RFQs Are Received and Logged
All incoming RFQs are recorded by the Sage Archivists in the Records Office. Each request is assigned an internal reference for tracking and auditing.
No RFQ moves forward without a complete intake record.
Internal Review and Validation
After logging, the RFQ is reviewed across inventory, finance, and logistics.
Internal checks include:
Available stock and production lead time.
Standard cost and current selling price.
Customer credit rating and limits.
Route capacity and seasonal risk.
If any check fails, the RFQ may be declined or returned with adjusted terms.
Pricing a Customer RFQ
RFQ pricing reflects more than the shelf price. It accounts for scale, effort, and risk.
An Arcane Treasurer reviews pricing before approval.
Approval and Customer Response
Large or high-value RFQs require approval before a quote is sent. Approval ensures margins and capacity remain within company rules.
Once approved, the RFQ response becomes a formal quote with:
Confirmed prices.
Delivery terms.
Payment conditions.
A validity period.
At this stage, no ledger posting occurs.
Worked Example
Customer RFQ Received by the Waterdeep Trading Company
Scenario Overview: The Baldur’s Gate Blacksmiths Guild plans a seasonal expansion serving caravan operators. They submit an RFQ for reinforced storage chests before committing funds.
RFQ as Received: This table shows the RFQ exactly as logged on receipt.
No stock is reserved at this point.
Internal Feasibility Review: The RFQ is reviewed by the planning, finance, and logistics teams.
Pricing Construction: Pricing is based on volume, handling, and transport.
Margins remain within policy.
Approval Record: Because of the deal size, approval is required.
Quote Sent to Customer: The approved RFQ response becomes a formal quote.
No ledger entries are created until acceptance.
Conversion to Order
If the customer accepts:
The quote converts to a sales order.
Inventory reservations are created.
Production is scheduled.
Revenue is posted only after delivery and invoicing.
If declined or expired, the RFQ is closed with no financial impact.
Final Thoughts
Customer RFQs protect both seller and buyer. They slow the process just enough to replace guesswork with proof. For the Waterdeep Trading Company, RFQs ensure every large sale begins with confirmed supply, fair pricing, and clear terms.
Handled correctly, an RFQ is not delayed. It is control.
Support the AD&D365 Project on Patreon. To grow this world, we’ve launched an official Patreon page where supporters can access exclusive content, tools, and training labs, and even influence the project’s future. Your support fuels more than just development; it expands the guildhall, forges new scrolls, and empowers the next generation of configuration wizards. Begin your journey: https://www.patreon.com/adnd365/
A Grateful Salute to Our Patrons. To all those who stand behind the vision, thank you for helping bring this world to life. Our Benefactors, Andre Breillatt and Eryndor Fiscairn‡, your boundless generosity fuels the arcane core of this project. Without your magic, the weave would falter. Our Apprentices, the spell engines turn, and the training labs thrive thanks to our current Apprentices: Michael Ramirez and Andreth Bael’Rathyn‡. Special thanks to our past Apprentices, whose contributions helped us get here: Ralf Weber, Wendy Rijners, Shashi Mahesh, Julia Tejera, Ben Ekokobe, Tiago Xavier, Naveen Boyinapelli, Marcos Tadeu Wolf, Kathryn Greene, Jason Brown, Mark Christy, and Ashish Singh.Our Initiates, Jesper Livbjerg, Peter Lorre, Gregory Brigden, and Martin Grahm, your commitment marks the start of the deeper path, stepping beyond mere observation into the active shaping of this realm. Our Followers, your steady presence along the journey is a beacon of encouragement: Rusty Cavalier,Eric Shuss, Sunil Panchal, Sarah D. Morgan, Nick Ramchandani, Daniel Kjærsgaard, and Tomasz Pałys. And our Voyeurs, Harry Burgh, Abdelrahman Nabil, and Basil Quarrell, ever watching from the shadows, clearly intrigued… but not enough to part with a single gold piece. Your silent curiosity is noted and mildly judged.
Want to design your own economic models in Faerûn? Get your own AD&D365 Environment and guides at adnd365.com/start, and request access to the public view of the current database at https://public.adnd365.com – Login npc@adnd365.com, Password N0nPl@yC#822!
Across Faerûn, trade does not happen from behind a desk alone. Clerks travel between guild halls, cartographers ride with caravans, and procurement officers cross regions to secure goods. The Waterdeep Trading Company acknowledges that its employees will spend company funds. The risk is not the spending itself, but the loss of control over how it is recorded, reviewed, and repaid.
Employee expense processing exists to solve that problem. It gives the company a straightforward way to let workers spend when needed, while keeping the ledger accurate and auditable. This article explains how employee expenses are handled, how they are coded using expense categories, and how those costs move from receipt to reimbursement within the Waterdeep Trading Company.
What Employee Expense Processing Is
Employee expense processing is the controlled process by which employees submit costs they paid personally for company-related duties. These costs are reviewed, approved, posted to the ledger, and then reimbursed from company funds.
Unlike vendor invoices, these expenses typically begin with a worker and end with a payment to the same worker. Because of this, strict rules and clear coding are required to prevent misuse and to keep costs tied to the correct purpose.
Why It Matters to the Waterdeep Trading Company
The Waterdeep Trading Company operates across cities, regions, and trade routes. Without proper expense processing:
Travel costs blend into overhead with no clarity
Small purchases disappear from cost tracking
Audits become guesswork instead of review
Workers lose trust if repayments are late or disputed
A defined expense process protects both the company and its people. It also ensures that travel, trade missions, and field work can continue without delay.
Core Expense Categories and Ledger Coding
Each employee expense must be coded to an expense category. The category controls posting behavior, allowed limits, and review rules.
The following table shows common expense categories used by the Waterdeep Trading Company, with Faerûn-specific flavor and clear accounting intent.
Each category ensures that costs are posted to the correct part of the ledger and can be reviewed by purpose rather than by person.
Expense Submission Flow
The standard flow for employee expenses follows a predictable pattern.
A worker incurs an expense while on an approved company activity.
The worker submits an expense report with dates, amounts, and category codes.
Receipts are attached when required.
A supervisor reviews the expense for the purpose and reason.
Approved expenses are posted to the ledger.
Reimbursement is paid to the worker.
This flow separates responsibility. Workers submit. Managers approve. Treasurer’s post and pay.
Worked Example One: Trade Route Travel
Elira Moonshadow, Special Courier, travels from Waterdeep to Daggerford on company business.
She pays for:
Horse hire for two days
One night at a roadside inn
Meals during travel
After approval, the posting is straightforward:
Debit travel, meals, and lodging expense accounts
Credit employee reimbursement liability
Payment clears the liability
Worked Example Two: Arcane Procurement Expense
Selene Duskbloom, Magical Trade Officer, purchases arcane inks while negotiating a Mage Guild supply contract.
Because arcane components affect regulated costs, this expense requires an additional approval by the Magical Trade Officer role before posting.
Policy Controls and Common Rules
To keep expenses fair and controlled, the Waterdeep Trading Company applies standard rules:
Meal costs have daily limits by region
Lodging must match approved inns where possible
Arcane purchases require role-based approval
Missing receipts require a written explanation
Personal and company expenses may not mix
These rules protect the ledger and simplify review.
How Expenses Appear in the Ledger
Once approved, expenses no longer belong to the worker. They belong to the company.
From a ledger view:
Each category posts to a defined expense account
The worker’s balance is cleared upon payment
Reports can be run by worker, category, route, or period
This allows the Arcane Treasurers to answer vital yet straightforward questions, such as which routes incur the highest support costs or which roles carry the highest field-expense burden.
Realms Aware Considerations
Faerûn adds its own challenges:
Some regions prefer barter equivalents
Guild fees vary by city
Travel risks change seasonal costs
Arcane supplies fluctuate in price due to demand
Expense categories allow these variations to be tracked without breaking structure.
Final Thoughts
Employee expense processing is not about limiting trust. It is about recording truth. The Waterdeep Trading Company succeeds because it allows workers to act quickly while keeping records clean, fair, and clear.
By using defined categories, consistent approvals, and proper posting, expenses support trade rather than obscure it.
Support the AD&D365 Project on Patreon. To grow this world, we’ve launched an official Patreon page where supporters can access exclusive content, tools, and training labs, and even influence the project’s future. Your support fuels more than just development; it expands the guildhall, forges new scrolls, and empowers the next generation of configuration wizards. Begin your journey: https://www.patreon.com/adnd365/
A Grateful Salute to Our Patrons. To all those who stand behind the vision, thank you for helping bring this world to life. Our Benefactors, Andre Breillatt and Eryndor Fiscairn‡, your boundless generosity fuels the arcane core of this project. Without your magic, the weave would falter. Our Apprentices, the spell engines turn, and the training labs thrive thanks to our current Apprentices: Michael Ramirez and Andreth Bael’Rathyn‡. Special thanks to our past Apprentices, whose contributions helped us get here: Ralf Weber, Wendy Rijners, Shashi Mahesh, Julia Tejera, Ben Ekokobe, Tiago Xavier, Naveen Boyinapelli, Marcos Tadeu Wolf, Kathryn Greene, Jason Brown, Mark Christy, and Ashish Singh.Our Initiates, Jesper Livbjerg, Peter Lorre, Gregory Brigden, and Martin Grahm, your commitment marks the start of the deeper path, stepping beyond mere observation into the active shaping of this realm. Our Followers, your steady presence along the journey is a beacon of encouragement: Rusty Cavalier,Eric Shuss, Sunil Panchal, Sarah D. Morgan, Nick Ramchandani, Daniel Kjærsgaard, and Tomasz Pałys. And our Voyeurs, Harry Burgh, Abdelrahman Nabil, and Basil Quarrell, ever watching from the shadows, clearly intrigued… but not enough to part with a single gold piece. Your silent curiosity is noted and mildly judged.
Want to design your own economic models in Faerûn? Get your own AD&D365 Environment and guides at adnd365.com/start, and request access to the public view of the current database at https://public.adnd365.com – Login npc@adnd365.com, Password N0nPl@yC#822!
The Waterdeep Trading Company oversees forges, breweries, tanneries, butcher halls, and alchemical works from the Sword Coast to the Moonsea. Each site produces goods needed by guilds, caravans, and settlements. To control these flows, the company relies on two core production models: input-driven manufacturing and output-driven manufacturing.
Choosing the correct method shapes cost, supply, and worker activity across the company. It is a key skill for any planner or foreman in Faerûn.
What Is Input-Driven Manufacturing
Input-driven manufacturing begins when materials arrive. The trigger is the availability of raw goods, not a customer request. Production cycles are set by supply rhythm, which may depend on weather, caravans, or seasonal harvests.
This method suits operations that must consume materials before spoilage or where bulk goods are expected to flow in steady waves.
Examples include:
Breweries working with incoming grain.
Tanneries receiving hides after large hunts.
Butcher halls where livestock arrives from nearby farms.
What Is Output-Driven Manufacturing
Output-driven manufacturing begins when a customer asks for something. A work order is created only when demand is confirmed. Goods are produced with accuracy, often following custom instructions or strict material controls.
This method suits operations where materials are rare or high cost, or where final goods require specialized work by artificers or master smiths.
Examples include:
Enchanted gear production.
Noble house commissions.
Custom alchemical batches.
Why These Approaches Matter
Both approaches determine how goods and coins move across the company.
They influence:
Inventory levels.
Cash flow.
Labor planning.
Resource allocation.
Selecting the right method ensures smooth trade across regions such as Waterdeep, Baldur’s Gate, and Calimport.
Worked Example One: Input Driven Example: Frostroot Ale in Silverymoon
When Frostroot Barley arrives from Icewind Dale, the Copperleaf Brewery begins a new brewing cycle. Barley cannot remain in storage for long, so production is triggered by shipments.
The table below shows how incoming material drives production volume.
This method keeps taverns supplied but increases storage during heavy harvest seasons.
Worked Example Two: Output Driven Example: Enchanted Shields in Waterdeep
The Arcane Smiths Hall starts production only when a signed order arrives. Mithral Dust and Phoenix Plume are tracked tightly by the Artificers Union, which makes this method ideal.
The table shows how materials are allocated only after orders are logged.
This approach protects rare resources and ensures predictable delivery.
Worked Example Three: Input Driven Example with Variable Outputs: Whole Animal Disassembly in Daggerford
When local farmers bring cattle to the Daggerford Butcher Hall, production begins immediately. This is input-driven because the animal itself is the trigger. One animal, however, can be broken into multiple cut profiles, each requested by nearby markets.
The final output varies because cutters choose different profiles based on condition, size, and planned sales.
The table below shows how three animals can produce different cut mixes. Each cut type has a standard yield range, but the actual yield depends on the animal’s size and the chosen breakdown pattern.
How This Works in Practice
The Butcher Hall begins work as soon as animals arrive. The cutters select the breakdown style based on:
Market demand in Waterdeep or Baldur’s Gate
Condition and age of the animal
Local festival needs
Storage space and salt levels
Order patterns from nearby taverns
This produces variable outputs and makes production unpredictable. It is a classic input-driven scenario because cutters respond to the arrival of livestock rather than to a fixed customer order.
This method is standard across Faerûn, where livestock flows depend on weather, harvesting, grazing conditions, and the health of nearby herds.
Realms Aware Considerations
Faerûn’s regions shape the choice of method.
Livestock production in Daggerford follows input cycles tied to farm supply.
Wandering herds in Amn cause irregular arrivals for local butcher halls.
Enchanted workshops in Waterdeep use output cycles to protect rare essence materials.
Coastal trade houses in Calimport favor output cycles for high-value seafood that must be allocated by order.
Final Thoughts
Input-driven manufacturing converts available goods into stock as soon as materials arrive. Output-driven manufacturing produces only when the market demands it. The Waterdeep Trading Company uses both across Faerûn to keep trade stable, predictable, and profitable.
Animal disassembly adds an extra layer of complexity, since a single input can yield many different outputs. This makes the method valuable for regions with active livestock markets and diverse customer needs.
Support the AD&D365 Project on Patreon. To grow this world, we’ve launched an official Patreon where supporters can gain access to exclusive content, tools, training labs, and even influence the future of the project. Your support fuels more than just development , it expands the guildhall, forges new scrolls, and empowers the next generation of configuration wizards. Begin your journey: https://www.patreon.com/adnd365/
A Grateful Salute to Our Patrons. To all those who stand behind the vision, thank you for helping bring this world to life. Our Benefactors, Andre Breillatt, and Eryndor Fiscairn‡, your boundless generosity fuels the arcane core of this project. Without your magic, the weave would falter. Our Apprentices, the spell engines turn and the training labs thrive thanks to our current Apprentices: Michael Ramirez and Andreth Bael’Rathyn‡. Special thanks to our past Apprentices, whose contributions helped us get here: Ralf Weber, Wendy Rijners, Shashi Mahesh, Julia Tejera, Ben Ekokobe, Tiago Xavier, Naveen Boyinapelli, Marcos Tadeu Wolf, Kathryn Greene, Jason Brown, Mark Christy, and Ashish Singh.Our Initiates, Gregory Brigden, and Martin Grahm, your commitment marks the start of the deeper path, stepping beyond mere observation into the active shaping of this realm. Our Followers, your steady presence along the journey is a beacon of encouragement: Eric Shuss, Sunil Panchal, Sarah D. Morgan, Nick Ramchandani, Daniel Kjærsgaard, and Tomasz Pałys. And our Voyeurs, Harry Burgh, Abdelrahman Nabil, and Basil Quarrell, ever watching from the shadows, clearly intrigued… but not enough to part with a single gold piece. Your silent curiosity is noted, and mildly judged.
Want to design your own economic models in Faerûn? Get your own AD&D365 Environment and guides at adnd365.com/start, and request access to the public view of the current database at https://public.adnd365.com – Login npc@adnd365.com, Password N0nPl@yC#822!
For over a century, the Waterdeep Trading Company has been the heartbeat of Faerûn’s trade. From the frost-kissed docks of Icewind Dale to the coastal bazaars of Calimport, the Company moves goods through every season with precision.
Success here is not based on speed alone. It depends on timing.
Seasonal demand planning is the art of predicting what will be needed, when it will be needed, and how to ensure it arrives just in time. It is how the Waterdeep Trading Company avoids stockpiling cloaks in the heat of Flamerule or running out of cider during the first toast of Highharvestide.
The Calendar of Commerce
Faerûn’s calendar tells more than time. It reflects culture, climate, and consumption. Every month carries specific market behaviors and patterns.
Waterdeep Trading Company studies these cycles carefully and layers them into every supply and logistics plan.
How the Company Forecasts Demand
Historical records are the backbone of the Company’s seasonal forecasting. Scribes maintain product movement scrolls dating back several generations.
Here are a few forecasting techniques in practice:
Rolling multi-year averages to compare monthly and festival-based trends across regions
Contracts and standing orders from temples, noble houses, and guilds which repeat annually
Predictive adjustments based on current market activity, such as harbor delays or rising prices from core vendors
Sentinel dispatches from field agents who report signs of early shifts in demand or local disruptions
The result is a structured forecast that balances tradition with the changing tides of trade.
Seasonal Labor and Staffing
The flow of goods depends on the flow of hands. The Waterdeep Trading Company plans its workforce as carefully as it does its inventory.
In Deepwinter, fewer shipments mean a heavier focus on warehouse security and internal audits
In Spring, hiring increases as couriers, carriers, and sorters are deployed to reopen stalled trade routes
In Summer, nearly every department grows. Market tents, brewery lines, and ship crews all need additional labor
In Autumn, specialized workers such as grain assessors and preservation technicians are deployed to lock in inventory before the freeze
Many workers are brought in on rotating seasonal contracts, often earning guild certifications for each successful campaign.
Managing Supplier Constraints
Not every vendor can scale with seasonal demand. Some are limited by harvest cycles, others by labor, and a few by magical interference.
To manage these risks, the Company maintains a supplier tier system:
Primary suppliers are those with strong delivery history and seasonal reliability
Secondary suppliers are used during peak demand or to fill gaps when primary vendors fall short
Specialist vendors are called upon for short seasonal bursts, such as rare spices during feast days or potion ingredients during cold snaps
Every procurement team tracks lead times and past performance to determine who to trust and when to switch.
Special Contracts and Priority Orders
Seasonal shifts also mean more contract-based orders. Some examples include:
Military garrisons requesting rations before planned campaigns
Temples ordering ceremonial garb and incense ahead of holy days
Mercenary companies securing bulk gear and potions in advance of expedition season
Nobles requiring finery and decor ahead of social functions
The Company sets aside protected inventory and often reserves wagon space or teleportation slots for these clients. They are built into seasonal forecasts as immovable pillars.
Transportation Planning by Season
Logistics can be the difference between profit and loss during seasonal transitions. Travel conditions change rapidly, and the Company prepares for these disruptions with dedicated planning ledgers.
Every route has a seasonal modifier and an action plan in place before the first sign of disruption appears.
What Happens After the Season Ends
The Waterdeep Trading Company reviews each season within ten days of its end.
Unused goods are either rotated to other regions or sold at a discount
Performance of forecasts is measured against actual sales
Surprises or anomalies are recorded in the forecasting grimoire for future adjustment
Lessons learned are shared across all Company locations
This cycle of planning, acting, and reviewing has been central to the Company’s growth and resilience.
Closing Thoughts
Seasons affect everything. Weather shifts harvests. Holidays shift demand. Travel restrictions shift logistics. But a business that plans for the seasons instead of reacting to them will always come out ahead.
Waterdeep Trading Company invites others to study how preparation drives prosperity.
To access trade records, planning templates, and regional demand data, visit adnd365.com/start and request access to the public trade network at https://public.adnd365.com.
