Volume 20, Chapter 1
The Business OS: Designing Your Business as Software
Definition
When MANIAC MINDZ finally moved off paper, the first attempt was a single spreadsheet with a tab for everything: customers, orders, payments, salaries, all in one file, all visible to anyone who opened it. It looked organized. It wasn't safe, and it wasn't really designed at all.
is the idea that a business is not really "a shop that sells things," it is an information system with departments as modules. Once you can see the whole business this way, designing software, or even just organizing paper, becomes a matter of answering one question, over and over.
Why does it matter whether you think of a tailoring shop, a bakery, or a garage as "an information system" at all? Because every department in a business is really just a place where specific information enters, gets used, and eventually leaves, salaries, measurements, stock counts, all of it. Seeing that clearly is what lets you design each department properly instead of piling everything into one shared file and hoping for the best.
Most people think they're building a tailoring business, or a bakery, or a garage. They're actually building an information system, the sewing, baking, or repairing is only one department, and answering one question, module by module, is exactly how professional business software gets designed, and exactly how a business without any software yet should organize its paper today.
The One Question That Designs Almost Everything
If this manual's authors were designing your business's systems from scratch, we would ask one question, repeatedly, for every single department:
That single question designs almost every form, document, software module, and workflow this chapter describes. Notice it's really Volume 02's Six Questions turned toward information specifically, and Volume 04, Chapter 8's access rule built directly into the design from day one.
Think in Modules, Not Paperwork
Instead of random forms and notebooks, think of the business as an operating system with departments as modules:
Core modules: Customers, Orders, Payments, Finance, Inventory, Machines, Patterns (Moulds), Suppliers, Documents, Human Resources, Reports.
The systems most businesses forget: Knowledge Base, Decision Log, Change Log, Incident Reports, Asset Photos, Password Vault, Training Library.
Each module below already has a full policy home elsewhere in this manual, this chapter's job is narrower: what data does each module actually need to hold, so that whether you buy software, build a spreadsheet, or keep it on paper, nothing important is left out.
Module by Module: What Each One Must Hold
Customer Module
Every customer needs a real profile, not just a name. Imagine someone returns after three years; the system should know everything.
| Field Group | Examples |
|---|---|
| Identity | Customer ID, name, phone, email, WhatsApp, birthday, address |
| Preferences | Favourite fabrics/colours, preferred fit, collar, sleeve, pocket, button style |
| History | Measurements, order history, invoices, payments, photos, complaints, returns |
| Relationship | Discount history, referral source, VIP status, communication history |
Policy home: Volume 04, Chapter 7 · Volume 15: Customer Management
Order Module
Every order deserves its own page: order number, customer, salesperson, dates, priority, status, designer/tailor assigned, pattern used and version, fabric, accessories, special instructions, measurements, fitting and approval history, production timeline, delivery, payment and balance, customer signature.
Policy home: Volume 16: Sales · Volume 19: Project Management (for large/special orders)
Payment Module
Many businesses only issue receipts. A real system also tracks: invoices, receipts, credit notes, debit notes, refunds, deposits, instalments, outstanding balances, overpayments, discounts, tax, payment method (cash, transfer, POS, cheque, mobile money), reference number, who received the payment, and a receipt image.
Policy home: Volume 16: Sales · Volume 11: Internal Controls (approval and cash handling)
Finance Module
Cash book, general ledger, trial balance, income statement, balance sheet, cash flow, budget, forecast, payroll, expense claims, petty cash, asset register, loan register, investor register, dividend register, tax register.
Policy home: Volume 04, Chapter 3 · Volume 07: Finance
Inventory Module
Raw materials (fabric, thread, elastic, buttons, zips, packaging, needles, oil, machine parts), finished products, rejected products, reserved stock, waste, returns, transfers, minimum/maximum stock levels, barcode/QR code, supplier, purchase and selling price, storage location, shelf/bin number.
Policy home: Volume 13: Inventory Management
Machine Module
Each machine becomes its own record: machine number, photo, serial number, brand, model, purchase date, warranty, location, assigned operator, maintenance schedule, oil changes, repairs, replacement parts, downtime, current status.
Policy home: Volume 04, Chapter 6: The Asset Register · Volume 02: Systems Thinking (the maintenance system itself)
Pattern (Mould) Module
Every pattern needs a base record, version history, and grading data. This is substantial enough to deserve its own full treatment, see Volume 05, Chapter 3: Sizes, Grading, and Measurement Intelligence.
Supplier Module
Supplier ID, products, prices, lead time, quality rating, delivery performance, contracts, payment terms, bank details, contact people.
Policy home: Volume 04, Chapter 7 · Volume 12: Procurement
Document Module
Every document needs a set of descriptive details, not just a folder to sit in: title, type, version, author, department, approval, effective date, review date, expiry date, status, confidentiality level, keywords, related documents.
Policy home: Volume 04: Business Records & Administration
Human Resources Module
Photo, employee ID, position, department, salary, allowance, bonus, commission, tax, bank details, emergency contact, next of kin, training, warnings, performance, promotions, leave, attendance, uniform, equipment assigned, password/access list, exit checklist.
Policy home: Volume 04, Chapter 5 · Volume 06: People & Roles
Reports Module
| Frequency | Typical Reports |
|---|---|
| Daily | Sales, cash, orders, production, inventory, attendance |
| Weekly | Profit, expenses, customer growth, machine downtime, quality |
| Monthly | Financial statements, payroll, KPIs, forecast |
Policy home: Volume 21: Performance Management · Volume 27: Business Metrics & Dashboards
The Systems Most Businesses Forget
This is where a Business OS goes from "good bookkeeping" to genuinely protecting the business's future:
| System | What It Captures | Why It's Easy to Forget | Policy Home |
|---|---|---|---|
| Knowledge Base | Every mistake and its solution, documented like a private Wikipedia | It feels like "just talking," not a record worth keeping | Volume 23: Knowledge Management |
| Decision Log | Why a machine was bought, why prices increased, why someone was hired, context future owners will need | Decisions feel obvious in the moment; they never stay obvious | Volume 22: Meetings & Decision-Making |
| Change Log | Every policy change, procedure update, price adjustment | Changes happen gradually; nobody notices there's no record of when or why | Volume 23: Knowledge Management |
| Incident Reports | Customer complaints, injuries, machine damage, power outages, fraud, theft, late deliveries, lost materials | Feels like paperwork for something already over | Volume 10: Risk Management |
| Asset Photos | A photo of every asset, alongside its register entry | Registers get filled with text; photos get skipped | Volume 04, Chapter 6 |
| Password Vault | Who owns the Facebook, Instagram, website, domain, hosting, email, bank tokens, Wi-Fi | Passwords live in one person's head or phone by default | Chapter 4 of this volume, Passwords and Access Management |
| Training Library | Videos, PDFs, checklists, quizzes, certificates | Training happens live, once, and is never captured for the next hire | Volume 23: Knowledge Management |
Every one of these seven "forgotten" systems is really Volume 02's systems-thinking philosophy applied one level up, not to doing the work, but to remembering why and how the work was ever decided. A business that keeps all seven has effectively given itself a permanent, searchable memory that outlives any one employee, including the owner.
Example Story: The Question That Redesigned the Whole Shop
Here's the full version of the one-spreadsheet-for-everything story from the start of this chapter.
The first attempt at moving off paper was a single spreadsheet with a tab for everything: customers, orders, payments, salaries, all in one file. (This is, not coincidentally, the exact mistake in Volume 04, Chapter 8's story.)
Running the one question from Section 2 against every tab fixed it in an afternoon: salary information needed to be seen by the owner and nobody else, so it moved to its own restricted file; customer preferences needed to be edited by reception but seen by tailors too, so it stayed shared but read-only for most roles; the machine maintenance log needed a completely different audience and a different rhythm than the sales log. No new software was bought. One question, asked seven times, redesigned the entire filing system on its own.
Common Mistakes
Software bought to "digitize the business" without first mapping who needs what data, and who shouldn't see it, just recreates the shared-spreadsheet problem in a nicer interface.
The Order Module needs the Customer Module's measurements; the Payment Module needs the Order Module's balance due. Design modules as a connected system, not separate islands, exactly like this manual's own cross-referencing.
A business can run for years on Customers, Orders, and Payments alone, right up until a key employee resigns holding the only copy of why things are done a certain way, which the Knowledge Base and Decision Log exist to prevent.
Quiz Yourself
- Knowledge Base, easy to overlook because people assume they will remember what they know.
- Decision Log, easy to overlook because decisions often happen in conversations or meetings and never get written down.
- Change Log, easy to overlook because small changes don't seem important at the time.
- Incident Reports, easy to overlook because everyone just wants to move on once the problem is fixed.
- Asset Photos, easy to overlook because taking photos feels unnecessary until something is lost, stolen, or damaged.
- Password Vault, easy to overlook because passwords are usually kept in one person's memory or scattered across notebooks and phones.
- Training Library, easy to overlook because teaching someone face to face feels quicker than writing the steps down.
Practice Exercise
- Pick one module from Section 4 that currently lives only on paper or in memory.
- Run the one question from Section 2 against it: what enters, who needs it, where should it live, who edits, who sees, when does it leave?
- Redesign that module's filing (paper or spreadsheet) based on the answers, before considering buying any software.
- Check whether any of the seven "forgotten systems" in Section 5 are completely missing from your business, and start the easiest one this week.
Quick Summary
Quick Summary
- Most businesses believe they're building "a shop." They're actually building an information system, with the trade as just one department.
- One question designs almost everything: what enters, who needs it, where stored, who edits, who sees, when it leaves.
- Core modules: Customers, Orders, Payments, Finance, Inventory, Machines, Patterns, Suppliers, Documents, HR, Reports, each with a full policy home elsewhere in this manual.
- The systems most businesses forget, Knowledge Base, Decision Log, Change Log, Incident Reports, Asset Photos, Password Vault, Training Library, are what let institutional memory outlive any one employee.
- Answer the one question before buying software, not after.