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.
AI assistants are not a new idea. They are the first real attempt to fix a problem management research documented seventy years ago and never actually solved for most people.
Every pitch for an AI assistant makes some version of the same claim: it will take the administrative weight off your day so you can focus on the work that actually matters. That claim is usually presented as new. It is not. It is the exact same claim that got made about executive secretaries, and it is backed by the same research, run three separate times across seven decades, always finding the same number.
The short version: a large and remarkably stable share of professional work, something close to 40 percent, is low-judgment administrative overhead rather than the work someone was actually hired to do. For most of the twentieth century, the only fix on offer was a personal secretary, and that fix was rationed almost entirely by seniority. AI assistants are the first attempt to offer that same relief to everyone else. Here is where that number comes from, and why the history matters for judging whether the new fix is real.
The first study
In 1951, a Swedish economist named Sune Carlson did something nobody had done before. He asked a group of managing directors to keep detailed diaries of their working days, logged in real time rather than reconstructed from memory afterward. The result, published as Executive Behaviour, is generally regarded as the first systematic empirical study of what managers actually do with their time, as opposed to what people assumed they did.
The picture that emerged was not flattering. Executive days turned out to be fragmented, reactive, and dominated by short bursts of low-level activity. Phone calls. Correspondence. Brief conversations. Interruptions. The romantic image of the executive locked away making weighty strategic decisions bore little resemblance to the diaries. Most of the day was consumed by administrative traffic that did not require an executive’s judgment at all, it just required someone competent to handle it.
Carlson’s book was not widely read at the time. It was sparse on conclusions and thin on theory. But the method survived. Two decades later, Henry Mintzberg ran a similar observational study and arrived at the same finding, dressed in more modern language. Managers do not spend their days thinking. They spend their days responding.
The finding keeps getting rediscovered
What is striking is not that this was found once. It is that it has been found repeatedly, in different decades, using different methods, on different populations of workers, and the number keeps coming back roughly the same.
In 2013, Julian Birkinshaw and Jordan Cohen ran a three year study of knowledge workers and published the results in Harvard Business Review under the title “Make Time for the Work That Matters.” Their headline finding: knowledge workers spend an average of 41 percent of their time on discretionary activities that offer little personal satisfaction and could be handled competently by someone else. Participants who went through a structured process to identify and shed that work cut desk work by roughly six hours a week and meeting time by two more.
Five years later, Harvard Business School’s Michael Porter and Nitin Nohria published the results of tracking 27 Fortune 500 CEOs for a full year, more than 60,000 hours of coded time-use data. It remains the most detailed public look at how chief executives actually spend their days. The finding was not that these people were lazy or undisciplined. It was that even at the very top of an organization, with every resource available to protect their time, a large share of it still got eaten by things that did not need a CEO to do them.
Three studies, seven decades apart, using diaries, surveys, and direct observation, converging on the same basic fact: a large and remarkably stable percentage of professional work is low-judgment administrative overhead. Not incompetence. Not poor discipline. Just the physics of running an organization, where information has to move, calendars have to align, and someone has to read the email before anyone can decide whether it matters.
Why the fix was always rationed
Here is the part of the story that gets skipped over. The research kept finding the same problem, but the solution it kept prescribing, dedicated administrative support, was never distributed according to who had the problem. It was distributed according to seniority.
A junior employee drowning in the same 41 percent of low-value work as a CEO simply absorbed it. There was no equivalent relief further down the org chart. And as email, shared calendars, and self-service scheduling tools spread through the 1990s and 2000s, even the people who had once had dedicated secretarial support increasingly lost it, on the theory that the tools themselves had closed the gap. The secretary and executive assistant roles contracted sharply. The underlying problem the research had documented did not contract with them. It just became something everyone quietly managed alone.
This is worth sitting with, because it means the historical relationship between “having administrative support” and “being more productive” was never really tested at scale. It was tested at the top of organizations, on people who already had every other advantage, and the results were treated as proof of a general principle that was never actually given the chance to apply generally.
What changes when the support is not rationed by rank
The research gives a fairly precise description of what kind of work is worth taking off someone’s plate: correspondence, scheduling, screening, routine drafting, information retrieval, status tracking. Not judgment work. Not relationship work. The mechanical layer underneath both of those things.
That is also, not coincidentally, close to the exact list of tasks that current AI tools are best at and are being adopted for first. Which suggests the honest way to think about AI assistants is not as a replacement for a human secretary, doing the same job with different hardware. It is closer to the first real attempt to deliver the same category of relief that Carlson’s executives had, to people who were never senior enough to be given it.
That reframe matters because it changes what the interesting question is. The old question, does an executive with a secretary outperform one without, was really a proxy for a different question that took seventy years to ask properly: how much of anyone’s professional capacity is being spent on work that has nothing to do with why they were hired, and what happens when that overhead gets pushed down toward zero for everyone, not just the people at the top of the org chart.
There is a genuine limit to the analogy, and it is worth naming rather than skating past. A human assistant carries judgment and institutional memory that took Carlson’s own subjects years to build with the people supporting them, knowing which call to interrupt a meeting for and which one to let go to voicemail. Whether that layer of judgment gets replicated, approximated, or simply left undone is not a question the old research can answer, because the old research was never testing for it. What it can tell us, with unusual consistency across seventy years of data, is the size and shape of the problem being solved. That part, at least, is no longer a mystery.
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.
Nobody has ever finished a day of data entry in an ERP system and felt like they’d been playing a game. That’s the problem gamification tries to solve, and after years of poking at enterprise systems, I’ve become convinced it’s one of the more underrated levers for actually getting people to use the software correctly.
The pitch
Gamification means borrowing the mechanics that make games compelling: points, badges, levels, progress bars, leaderboards, and bolting them onto tasks nobody would otherwise choose to do carefully. In an ERP context, that might mean a purchasing clerk earning a badge for zero-error PO entry for a month, a warehouse team seeing a live leaderboard of pick accuracy, or a new hire working through a “level up” onboarding path instead of a 40-tab training binder.
It’s not a gimmick dreamed up by a UX consultant with too much time on their hands. There’s real academic backing here. A well-cited study built a gamification prototype on top of SAP ERP and tested it with 112 users using the standard technology acceptance model; enjoyment, flow, and perceived ease of use all improved meaningfully. Another case study found that adding game mechanics to SAP increased user “telepresence” (basically, how engaged people felt while using the system) by nearly 30%. The underlying research consistently shows gamified ERP leads to better data entry and fewer errors, which, if you’ve ever had to clean up a mangled inventory count, is not a small thing.
Why now
The gamification market broadly is expected to roughly double by the early 2030s, and enterprise software is a big part of that growth. What’s changed recently is the mechanism. The old playbook was static: points, badges, a leaderboard bolted onto the sidebar, forget about it. The new playbook is AI-driven, with personalized nudges, dynamic feedback loops, and coaching that adapts to what an individual user is struggling with rather than a one-size-fits-all reward ladder. Microsoft’s Power Apps approach is a good example of the direction things are heading, embedding game-like mechanics directly into workflows rather than treating gamification as a bolt-on layer, which cuts rollout time from months to weeks.
HR and training modules are seeing the fastest uptake, which makes sense. That’s the part of ERP most people already expect to feel like a course rather than a chore, so it’s the easiest wedge for game mechanics to get in the door.
The catch
Here’s the part worth sitting with before you get excited and start slapping badges on every screen: a huge share of gamification efforts flop. The research puts the failure rate at around 80% when organizations default to generic points and leaderboards without actually designing for the behavior they want to change. A leaderboard that just measures raw transaction volume will train people to enter data fast and sloppy, not accurately. Badges nobody respects become wallpaper. And gaming mechanics don’t land the same way with every personality; some people are motivated by competition, some by mastery, some find the whole thing patronizing. The smart implementations keep traditional training and recognition paths alongside the gamified ones rather than replacing them outright.
Legacy systems are also a real drag here. If you’re still running SAP ECC or an older on-prem instance, bolting gamification on top usually means custom middleware, which stretches timelines and adds a maintenance burden nobody budgeted for. It’s a much easier build on modern cloud ERP with decent APIs.
The tinkerer’s takeaway
If I were experimenting with this on a real system today, I’d start narrow. Pick one painful, error-prone workflow, define the specific behavior I actually want to reinforce (not just “more activity”), and build a small feedback loop around that: a progress indicator, a streak counter, something visible and honest. Skip the company-wide leaderboard until you’ve proven the mechanic works on a small team that won’t quietly resent it.
ERP software has a reputation for being where enthusiasm goes to die. Gamification isn’t going to fix bad process design or a system nobody wanted in the first place, but done with a little more thought than “add badges,” it’s a genuinely useful tool for making the boring but important parts of enterprise software a little more bearable.
If you want help thinking through where gamification actually fits in your own ERP rollout, that’s exactly the kind of thing I help people work through. Get in touch at adnd365.com/start.
I’ve been building and implementing ERP systems for a long time. Most of them share the same skeleton underneath: a monolithic database that owns the authoritative state, application code layered on top to enforce business rules, and a UI wrapped around the whole thing so humans can interact with it.
That pattern has served enterprise operations well for thirty years. It’s proven, stable, and deeply integrated into how organizations run.
Headless ERP Is Real Progress – and a Useful Stepping Stone
The industry’s shift toward headless ERP is a genuine improvement. The pitch is compelling: decompose the monolith, expose business capabilities as APIs, and let any interface – web, mobile, AI copilot – consume them. This breaks the tight coupling between the UI and the data, which creates real flexibility.
But it’s worth being clear about what headless ERP changes and what it doesn’t.
The database is still the authoritative system of record. The business logic is still baked into the same application layer. What’s changed is that the user interface abstraction has moved one level up the stack. An AI agent now calls the same procedure that a form used to call. The underlying state management, the write model, and the integrity model are largely the same.
That’s a meaningful evolution. It’s just not the same thing as rethinking the architecture from the ground up. The major ERP vendors are building AI agents, tool APIs, and conversational interfaces as fast as they can – and those capabilities are genuinely valuable. But in most cases, the mutable relational database remains the authoritative core. AI is a new interaction layer, not a new architecture.
What Would a Truly AI-Native ERP Look Like?
That raises a useful design question: if we weren’t constrained by the existing architecture, what would we actually need an ERP to do?
An ERP needs to:
Record that business events happened and cannot be undone
Derive current state from those records
Enforce rules about which events are permitted
Report on any slice of history or current state
Coordinate with other parties and nodes
Notice that “store mutable rows in a relational schema” is not in that list. That’s an implementation choice that has become a deeply embedded assumption – but it isn’t the only one available.
What if the ledger was the database?
Not a blockchain. Not distributed consensus. Not tokens. Just immutable, append-only, typed records – structured text that any human or machine can read, that hashes itself into a verifiable chain, and that never requires a rollback because facts don’t change, only new facts get added.
I’ve been building exactly this. The prototype uses plain Markdown files as the authoritative store. Every business posting – a journal entry, an inventory movement, a document – is a Markdown file containing machine-canonical JSON and human-readable context. There is no database. Current state is a projection, rebuilt from the ledger on startup and kept live in memory. The only write is an atomic append.
Fifty-seven passing tests cover balanced accounting, inventory authority, immutable document chains, verified replication, disconnected-node convergence, and same-origin fork rejection. The balance sheet balances. The inventory reconciles. Two disconnected nodes post independent transactions and converge without conflicts – without any consensus protocol.
AI Becomes the Only Interface
Here’s where the architecture shift becomes genuinely interesting.
In a ledger-first, text-native ERP, there is no form to fill out. There is no screen to navigate. There’s a typed command interface and a set of hard invariants. An AI agent – or a human typing natural language – submits an intent. The system validates it against policy, checks the invariants, and either appends an immutable record or returns a precise rejection.
The UI doesn’t exist until it needs to exist. When a warehouse manager asks “what’s on hand at site B?”, the answer is a live projection query. When a CFO asks “show me the aging receivables by customer segment”, that’s a reporting query – constructed dynamically against the ledger, not a pre-built report someone maintained for years. When a purchasing agent says “draft a PO for the coffee beans I bought last quarter at the same price,” the AI reads the ledger history, constructs the command, and submits it for approval.
There’s no screen configuration. There’s no report builder. There’s no workflow designer. The AI is the interface, the report, and the workflow – and the ledger makes sure it can’t lie about the numbers.
Policies Are the Contracts, Not Code
The hardest part of any ERP implementation isn’t the software. It’s the rules: approval thresholds, posting profiles, accounting mappings, regulatory requirements, credit limits. In traditional ERP these are baked into configuration tables, workflow definitions, and custom code – all of which require IT to change and none of which an AI can inspect or reason about directly.
In a ledger-first design, policy is a first-class ledger record.
An approved policy revision is itself immutable, effective-dated, and hash-linked. It says: “For purchase orders above $10,000, two approvals are required, and the expense must post to account 6100.” That policy record is readable by both the enforcement engine and an AI agent explaining a rejection. When the CFO updates the threshold, a new policy revision is posted to the ledger – the old one doesn’t disappear, it simply becomes historical. You can audit every rule change the same way you audit every financial transaction.
The objects – products, customers, accounts, locations – are extensible definition records, not schema columns. Adding a new attribute to a product doesn’t require a database migration. It’s a new field in the next definition revision. The schema is the business model; the ledger stores the evolution of the business model alongside the business events.
A Different Starting Point
This model raises questions worth sitting with, especially for architects and business leaders thinking about long-term platform choices.
If the authoritative store is a text ledger that any AI can read directly, the relationship between data and the systems that manage it changes. If policy is data rather than embedded configuration, it becomes inspectable and auditable in ways that configuration screens aren’t. If the UI is assembled dynamically rather than maintained as a static artifact, the cost of adapting to change drops.
Existing ERP platforms are adding AI agents, tool APIs, and conversational interfaces at a rapid pace – and those are genuine improvements on top of proven foundations. The question this architecture raises isn’t whether those platforms have value. They clearly do. It’s whether the database-first foundation is the only viable path, or whether there are scenarios where a ledger-first approach offers distinct advantages.
What I’m describing is a different starting point – not a replacement for everything an ERP does today, but an exploration of whether the database-first model is the permanent default or one point on a longer architectural trajectory.
What This Isn’t
To be direct about what I’m not claiming:
This is a prototype. It has 57 passing tests, not 57,000 customers. It doesn’t have digital signatures, authenticated transport, encryption, crash recovery, or performance benchmarks at scale. The hard work of production ERP – currencies, taxes, period close, consolidation, regulatory certification – hasn’t been done.
I’m also not claiming that organizations should abandon well-functioning ERP implementations. For continuously connected operations under one administrative authority, a traditional ERP database remains a strong and well-understood answer.
But for organizations that need:
Independent nodes that operate offline and converge later
AI governance with a hard execution boundary and auditable decisions
Extensible business objects without vendor schema lock-in
Deterministic history reconstruction – what was true on day one through today
Policies as auditable data – not configuration only IT can change
…the ledger-first, AI-native model deserves serious evaluation. It’s not a theoretical construct. The balance sheet balances. The inventory reconciles. The tests pass.
The Question Worth Asking
The ERP industry’s investment in AI capabilities is accelerating. In most implementations today, those capabilities are built as interfaces to the existing architecture. The database is still authoritative, and AI is the new interaction layer.
What if the AI wasn’t the client – what if the ledger was, and the AI was one more authorized agent submitting typed, policy-governed commands alongside the humans?
That’s not headless ERP. That’s a different architecture.
I’m writing this as someone who has implemented ERP systems commercially and is now prototyping an alternative architecture – not to sell a product, but to test whether the assumptions we’ve been building on are as permanent as we’ve treated them.
The source code, architecture specification, and worked scenarios are in an active research project. Happy to dig into specifics in the comments below.
Every ERP concept in this lab has a CRM twin. The names changed, the forms got wider, and there are more required fields, but the underlying business logic is the same. This lab maps what we already know to where it lives in Finance and Operations.
We are not building anything new yet. We are reading, navigating, and comparing. By the end, the D365 F&O navigation should feel like a dialect of a language we already speak.
Overview
This lab maps six core CRM entities to their ERP equivalents. We will navigate to each F&O form, compare the record structure to what we know from CRM, and identify which fields are new, which are renamed, and which behave differently.
We will complete six activities:
Open a customer record and compare it to a CRM account.
Review customer groups and compare them to CRM account types or segments.
Open a released product and compare it to a CRM product catalog entry.
Navigate the site and warehouse hierarchy and understand physical inventory tracking.
Open a vendor record and understand the purchase side of the same entity model.
Review currency codes and understand multi-currency in ERP.
Each activity is a guided navigation exercise. No records are created or modified.
Objective
By completing this lab, we will be able to navigate six core F&O entity forms and explain the CRM-to-ERP mapping for each.
The following table defines the target outcomes for each entity mapping exercise.
TABLE: LAB TARGET OUTCOMES
Reference Data
The following reference values support navigation during this lab. All records already exist in the Contoso Coffee database.
In every guild hall across the Sword Coast, from the marble counting houses of Waterdeep to the timber-framed trade posts of Baldur’s Gate, there exists an unspoken question. What separates a thriving merchant house from one that folds after a single bad season?
Adventurers have long been judged by strength, dexterity, constitution, intelligence, wisdom, and charisma. These scores tell the story of what a person can lift, dodge, endure, learn, perceive, and persuade. But guilds and trading companies are not people. They are living systems built on coin, contracts, caravans, and control.
The Waterdeep Trading Company does not measure itself by the arm strength of its porters or the charm of its negotiators. It measures itself by six core business ability scores. Capital Base, Operational Speed, Stability, Planning Acumen, Control Discipline, and Trade Standing. Together, these scores provide a complete picture of how a business performs under pressure, navigates opportunity, and sustains itself across seasons and storms.
This system is used by guild clerks, senior factors, and financial scribes to evaluate performance, compare branches, and make decisions about expansion, investment, and partnerships. The scores are not abstract. They shape daily outcomes, from whether a contract is honored to whether a caravan reaches its destination intact.
This article explains how the Waterdeep Trading Company uses business ability scores to measure organizational health, predict risks, and maintain one of the most respected operations in the Realms.
What Business Ability Scores Are
Business ability scores are numerical ratings that describe the functional capacity of a guild, trading house, or merchant operation. Just as adventurers are rated on a scale of 3 to 18 for physical and mental attributes, businesses are rated on the same scale for operational and financial attributes.
Each score measures a specific dimension of performance. Low scores indicate weakness or vulnerability. High scores indicate strength and resilience. A score of 10 or 11 represents average competence for an established guild. Scores below 8 suggest critical deficiencies. Scores above 15 suggest exceptional capability.
These scores are not static. They shift in response to events, decisions, investments, and market conditions. A guild that loses its warehouse to fire may see its Stability score drop by 3 points. A guild that secures exclusive contracts with the Lords’ Alliance may see its Trade Standing rise by 2 points.
The six core scores are used individually and in combination to calculate derived metrics that describe real operational outcomes.
The Six Core Business Stats
This table defines the primary attributes used to assess a business’s strength and health in Faerûn.
Capital Base, CAP
Capital Base measures financial muscle. It represents the total amount of liquid coin, available credit, vaulted reserves, and purchasing power that a business can deploy on short notice.
A guild with a high Capital Base can afford bulk purchases at discount rates, fund emergency repairs without hesitation, and sustain operations through lean months. A guild with a low Capital Base struggles to keep shelves stocked, cannot negotiate favorable terms, and must turn away profitable opportunities due to a lack of funds.
Capital Base is used when a business needs to outbid rivals, secure rare materials, pay unexpected tariffs, or survive a season where revenue drops below expenses. It determines whether a company controls its suppliers or is controlled by them.
A score of 8 or below means the guild operates hand to mouth, always one delay away from insolvency. A score of 15 or above means the guild can absorb shocks, invest in growth, and dictate terms to weaker partners.
Operational Speed, OPS
Operational Speed measures how fast a business acts. It represents the ability to fulfill orders promptly, reroute caravans in response to danger, process customer requests without delay, and handle surges in demand.
A guild with high Operational Speed completes contracts ahead of schedule, adapts to shifting markets, and captures time-sensitive opportunities. A guild with low Operational Speed creates backlogs, misses deadlines, and loses customers to faster competitors.
Operational Speed is used when goods must be delivered by a specific festival date, when a workshop must pivot to produce a different item on short notice, or when emergency repairs are needed to keep a production line running.
A score of 8 or below means the guild is perpetually behind, with frustrated customers and missed opportunities. A score of 15 or more means the guild sets the pace of the market and can react to changes faster than rivals can plan for them.
Stability, STA
Stability measures endurance under pressure. It represents the ability to absorb losses, withstand delays, survive fines or penalties, and continue operating when circumstances turn hostile.
A guild with high Stability can endure a failed caravan, a spoiled shipment, a warehouse fire, or a contract dispute without collapsing. A guild with low Stability teeters on the edge of ruin, where a single bad event can close its doors permanently.
Stability is used when goods spoil in transit, when bandits destroy a shipment, when tariffs double unexpectedly, when a key partner goes bankrupt, or when a plague disrupts supply chains for months.
A score of 8 or below means the guild has no cushion for error and cannot survive adversity. A score of 15 or above means the guild can weather storms that would destroy lesser operations and emerge intact.
Planning Acumen, PLN
Planning Acumen measures foresight and judgment. It represents the ability to forecast demand, anticipate price shifts, choose reliable suppliers, set profitable margins, and avoid costly mistakes.
A guild with high Planning Acumen purchases materials before prices spike, avoids inventory that will not sell, prices goods to maximize profit without losing customers, and identifies emerging markets before competitors do. A guild with low Planning Acumen overbuys goods that sit unsold, underprices valuable items, and makes purchasing decisions based on guesswork.
Planning Acumen is used to determine how much stock to order for the winter season, decide whether to expand into a new region, set prices for a new product line, or evaluate the reliability of a potential supplier.
A score of 8 or below means the guild makes poor decisions that erode margins and waste resources. A score of 15 or above means the guild anticipates market movements and positions itself ahead of the curve.
Control Discipline, CTR
Control Discipline measures internal order and rule-keeping. It represents the ability to enforce procedures, detect fraud, maintain accurate records, ensure contract compliance, and prevent waste or theft.
A guild with high Control Discipline has clean books, reliable audits, trusted employees, and consistent processes. A guild with low Control Discipline suffers from embezzlement, sloppy record keeping, contract violations, and operational leaks that drain profit.
Control Discipline is used when conducting financial audits, investigating discrepancies in inventory counts, enforcing contract terms with suppliers, or ensuring that employees follow established procedures.
A score of 8 or below means the guild is vulnerable to fraud, mistakes, and regulatory penalties. A score of 15 or above means the guild operates with precision and can be trusted by partners, investors, and guilds.
Trade Standing, REP
Trade Standing measures how the market views the business. It represents reputation, trustworthiness, influence with guilds and nobles, access to favorable credit terms, and the ability to negotiate from a position of strength.
A guild with high Trade Standing enjoys preferred supplier relationships, can secure credit on favorable terms, gains access to exclusive contracts, and receives lenient treatment when disputes arise. A guild with low Trade Standing must pay cash up front, is denied opportunities, and struggles to find partners willing to work with them.
Trade Standing is used when negotiating payment terms, seeking membership in a prestigious guild, applying for licenses or permits, or requesting favors from influential contacts.
A score of 8 or below means the guild is viewed as unreliable and unworthy of trust. A score of 15 or above means the guild opens doors that others cannot access and commands respect across the Realms.
Derived Business Metrics
Core ability scores are useful on their own, but they become even more powerful when combined to calculate derived metrics. These metrics describe specific operational outcomes that matter to daily performance.
This table shows how core stats combine into practical outcomes.
Liquidity
Liquidity is calculated by adding Capital Base and Control Discipline. It measures whether a business can meet its financial obligations when they come due. A guild with high Liquidity has enough coin on hand and disciplined processes to ensure payments are made on time. A guild with low Liquidity may have coin but lose track of when payments are due, or may have excellent record keeping but insufficient funds to cover debts.
Throughput
Throughput is calculated by adding Operational Speed and Stability. It measures the volume of goods that can be moved safely without exceeding the system’s capacity. A guild with high Throughput can handle large orders, seasonal surges, and complex logistics without collapsing under the load. A guild with low Throughput becomes overwhelmed when demand spikes and suffers delays or failures.
Margin Control
Margin Control is calculated by adding Planning Acumen and Control Discipline. It measures how consistently a business generates profit. A guild with high Margin Control prices goods intelligently and enforces cost controls that prevent waste. A guild with low Margin Control makes erratic profits, with some quarters highly profitable and others deeply unprofitable.
Market Reach
Market Reach is calculated by adding Trade Standing and Operational Speed. It measures how far a business can effectively sell its goods. A guild with high Market Reach can deliver products quickly to distant cities and has the reputation to close deals in unfamiliar markets. A guild with low Market Reach is confined to local sales and struggles to expand beyond familiar territory.
Risk Exposure
Risk Exposure is indicated by low Control Discipline. It measures the likelihood of damage from internal failures. A guild with high Risk Exposure is vulnerable to fraud, contract violations, regulatory fines, and operational mistakes that create financial harm.
Reading a Business Profile
To illustrate how these scores work together, consider a mid-sized merchant house operating out of Baldur’s Gate. The house specializes in importing textiles from Calimport and selling them throughout the Sword Coast.
This table shows the ability scores for a fictional merchant house.
Derived Metrics:
Liquidity: 14 + 9 = 23. Adequate ability to meet obligations, though control weaknesses introduce some risk.
Throughput: 10 + 12 = 22. Moderate capacity can handle standard volumes.
Margin Control: 15 + 9 = 24. Good planning is offset by weak controls; profits are strong but inconsistent.
Market Reach: 13 + 10 = 23. Solid reach can sell across the Sword Coast.
Risk Exposure: Control Discipline of 9 indicates an elevated risk of fraud or operational errors.
Interpretation
This merchant house has strong margins and good market standing, but weak controls. Growth has outpaced discipline. The business is profitable and well-positioned for expansion, but a single fraud incident, contract violation, or sloppy record-keeping error could cause significant damage.
The recommended action would be to invest in improving Control Discipline before pursuing further growth. This might include hiring an experienced auditor, implementing stricter inventory checks, or establishing formal approval processes for major expenditures.
Using Business Ability Scores in Daily Decisions
Guild clerks and senior factors use these scores to guide decisions across a range of scenarios.
When evaluating a potential partnership, they compare Trade Standing and Control Discipline scores. A partner with high Trade Standing but low Control Discipline may bring valuable connections but also introduce operational risk.
When planning for seasonal demand surges, they examine Operational Speed and Stability. If both scores are low, the guild may need to decline large orders or risk collapse under the load.
When deciding whether to extend credit to a customer, they review the customer’s Capital Base and Trade Standing. A customer with a strong reputation but weak capital may need shorter payment terms.
When assessing the viability of a new trade route, they calculate Market Reach and compare it with the route’s distance and complexity. If Market Reach is insufficient, the route may fail due to delivery delays or the inability to negotiate favorable terms in unfamiliar cities.
These scores are not abstract academic measures. They are practical tools used daily to evaluate risk, allocate resources, and make choices that determine whether a business thrives or fails.
Realms Aware Considerations
Business ability scores are influenced by location, market conditions, and external events. A guild operating in Waterdeep may have higher Trade Standing due to proximity to influential nobles and guild councils. A guild operating in a frontier settlement may have lower Operational Speed due to limited infrastructure and unreliable supply chains.
Scores can shift rapidly during crises. A plague that disrupts trade routes may reduce Operational Speed and Stability across an entire region. A successful diplomatic mission that secures favorable trade agreements may increase Trade Standing for all guilds affiliated with the sponsoring faction.
Guilds with diversified operations across multiple cities may have different scores in each location. The Waterdeep Trading Company may have a Capital Base of 16 in its home city but only 11 in its Baldur’s Gate branch, reflecting differences in local reserves and access to credit.
Senior factors track score changes over time to identify trends. A steady decline in Control Discipline may indicate that internal processes are breaking down and require immediate attention. A steady increase in Planning Acumen may indicate that recent hires or training programs are paying off.
Final Thoughts
Business ability scores let a guild feel alive, measured, and fallible, just like any adventuring party. They provide a common language for evaluating performance, comparing operations, and making decisions grounded in evidence rather than intuition.
The Waterdeep Trading Company uses these scores to maintain discipline, anticipate risks, and ensure that every branch operates with the strength needed to survive in the competitive markets of Faerûn. Whether managing a warehouse, negotiating a contract, or planning for the next season, these six scores guide every choice and shape every outcome.
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 ourPatrons. 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. OurApprentices, 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, Jeff Stiles,Harry Burgh, 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, 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!
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!
A Tinkerers Notebook 