// CaseStudiesPage.jsx
//
// Replaces the generic capture-page treatment for "/case-studies/" with
// real content - but not fabricated customer case studies. Babji Food
// Industries is our one real pilot (already covered once, on Home's Trust
// section) and has no reported outcome metrics yet, so inventing 2-3 more
// named companies with fabricated results was explicitly ruled out. These
// five scenarios instead walk through how the real modules (linked by
// name) solve real, common problems - no company name, no invented
// percentage/outcome, explicitly labeled "Illustrative Scenario" in every
// instance so it's never mistaken for a customer result. "What it takes
// for us to publish a real case study" states our actual bar (measured
// result + explicit permission) so the absence of one reads as principled,
// not evasive. A capture CTA at the bottom stays for when real case
// studies exist to publish.
//
// Loaded as a classic (non-module) Babel-transformed script - see
// index.html's header comment.
const SCENARIOS = [
{
tag: "Illustrative Scenario",
title: "Finding the wastage that only showed up at month-end stocktake",
setup:
"A multi-stage processing operation - raw material moving through several production stages before it becomes a finished product - has always measured yield loss the same way: physically count what's left at the end of the month and back-calculate what went missing. By the time the number shows up, the stage that caused it is long finished, and nobody can say which shift, which batch, or which stage the loss actually happened at.",
howItWorks:
"The Production & WIP Workflow Engine's double-entry ledger tracks exactly what enters and leaves each stage as it happens, not once a month. A wastage evaluation runs per stage, per cycle - not once for the whole plant - so a yield-loss spike at one specific stage is visible while the batch is still on the floor, not weeks later. The same event stream also flags a negative in-progress balance automatically, which today gets caught by a physical count, if it gets caught at all.",
modules: [
{ slug: "production-workflow", label: "Production & WIP Workflow Engine" },
{ slug: "analytics-dashboards", label: "Analytics & Dashboards" },
],
},
{
tag: "Illustrative Scenario",
title: "Knowing what's actually in stock before promising a delivery date",
setup:
"A distribution business runs two warehouses - a main site and a smaller depot. Stock gets moved between them informally, and the only way to know what's really available at the depot is a phone call to whoever's standing in it. Sales ends up promising delivery dates based on what the system says is in the main warehouse, without knowing the depot already covers it - or doesn't.",
howItWorks:
"Multi-Warehouse Management keeps a real balance per product, per warehouse, updated by the same events that drive every other module - not a separate spreadsheet reconciled after the fact. A stock movement that doesn't specify a warehouse resolves to the company's default one automatically, instead of failing or being logged against the wrong location. Sales and dispatch see the same live numbers, so a delivery promise is based on what's actually there.",
modules: [
{ slug: "inventory", label: "Inventory Management" },
{ slug: "warehouses", label: "Multi-Warehouse Management" },
],
},
{
tag: "Illustrative Scenario",
title: "Keeping production running when a delivery slips",
setup:
"A manufacturer's production schedule depends on raw material arriving on time. Purchase orders, the goods-received desk, and the production floor run as three separate systems today - so when a delivery is partial or late, the production team often finds out only when they physically run out mid-shift, not before.",
howItWorks:
"Purchase Orders & GRN tracks exactly what was received against what was ordered, line by line - a partial delivery is a tracked status, not a rounding error absorbed into the total. Because that received stock flows straight into Inventory and the Production workflow through the same event stream, a shortfall is visible as a live inventory number before the floor runs dry, not discovered by an empty bin.",
modules: [
{ slug: "purchase-grn", label: "Purchase Orders & GRN" },
{ slug: "production-workflow", label: "Production & WIP Workflow Engine" },
],
},
{
tag: "Illustrative Scenario",
title: "A commission number nobody can defend when it's questioned",
setup:
"A distribution business pays several brokers on different commission structures - some per unit, some a percentage above a volume threshold. Today that's reconciled by hand at month-end, cross-referencing a spreadsheet against whichever deals actually closed. When a broker questions a number, there's no record of exactly how it was calculated at the time - only a formula that may already have been edited since.",
howItWorks:
"The Business Rules Engine assigns a real calculation strategy - per-unit, per-weight, percentage, or threshold-based - to each broker individually, and applies it automatically as deals close. The moment a rule fires, an immutable snapshot of that exact calculation is stored with the record, so a commission dispute has a real, timestamped answer behind it instead of a spreadsheet reconstruction - and editing the rule later never rewrites what already happened.",
modules: [
{ slug: "business-rules", label: "Business Rules Engine" },
{ slug: "brokers", label: "Broker Management" },
],
},
{
tag: "Illustrative Scenario",
title: "The one person everyone waits on",
setup:
"A growing manufacturer wants a warehouse supervisor to manage dispatch directly, and a part-time bookkeeper to see purchase and inventory numbers - without either of them touching pricing rules or approving a purchase order. With most systems offering only \"full admin\" or \"basic user,\" that split means either over-granting access or making one person the approval bottleneck for every request.",
howItWorks:
"Roles & Permissions are defined per company as real templates, with independent View, Contribute, or Manage access set separately for fleet, sales, purchase, inventory, production, and more. A warehouse supervisor gets Manage on dispatch and nothing on pricing; a bookkeeper gets View-only on purchase and inventory. It's enforced at the API level, not just hidden in the interface, so the boundary holds even for someone who knows the right URL.",
modules: [{ slug: "roles-permissions", label: "Roles & Permissions" }],
},
];
const CASE_STUDY_BAR = [
{
title: "A measured result, not a vibe",
body: "Wastage reduced by a real percentage, dispute turnaround cut from days to hours - something we can actually point to, not a paraphrased compliment.",
},
{
title: "The customer's explicit permission",
body: "Named, with their sign-off on exactly what's published - never assumed from a demo call or a friendly conversation.",
},
{
title: "Something that would hold up if you asked them directly",
body: "We'd rather under-publish than publish something a customer would hesitate to confirm if you called them yourself.",
},
];
const CASE_STUDY_FAQS = [
{
q: "Why not just publish results from Babji Food Industries here?",
a: "Because we don't have a measured, reportable result to share yet - see \"What it takes for us to publish a real case study\" above. We'd rather wait and get it right than round up an early impression into a stat.",
},
{
q: "Can I talk to your pilot partner directly?",
a: "Reach out through Contact and we'll see what we can arrange - we're not going to promise a reference call from a single early pilot without checking with them first.",
},
{
q: "When will the first real case study be published?",
a: "No fixed date - as soon as there's a real, permissioned result to report. Leave your details below and we'll notify you directly, not through a newsletter.",
},
];
function CaseStudiesPage() {
useDocumentMeta(
"Case Studies - SkelBiz Manufacturing Operations Platform",
"How SkelBiz's real modules solve common manufacturing and distribution problems - illustrative scenarios, not fabricated customer results, since we're early and won't pretend otherwise."
);
return (
<>
Case Studies
How this actually solves real problems.
We have one real pilot partner and no polished case study to show yet - so instead of inventing
customers, here's exactly how the real modules work against problems every manufacturer
recognizes.
These are illustrative scenarios, not customer case studies. No company names, no
invented outcome numbers - just an honest walkthrough of what the real modules do when this
situation comes up. Our one real pilot partner, Babji Food Industries, is covered on the Home page.
{SCENARIOS.map((s) => (
{s.tag}
{s.title}
The situation
{s.setup}
How the real modules handle it
{s.howItWorks}
))}
What it takes for us to publish a real case study
The same bar we apply everywhere on this site - see our{" "}
About page
{" "}
on how we build.
{CASE_STUDY_BAR.map((b) => (
))}
Frequently asked
{CASE_STUDY_FAQS.map((item) => (
))}
Want to be our next real case study?
We'd rather publish a real one with your name on it, with your permission, once there's a
measured result to report. Leave your details and we'll notify you when the first ones go
live - or talk to us about becoming the next pilot partner.
);
}