Customer story · template

The shape every story
on this page follows.

A single page per customer. Around 600–900 words. Always reviewed by the customer before it goes live. Use the fields below as a brief; we'll fill in whatever's missing through a couple of back-and-forth questions, and you sign off on the final draft.

Section 1

The customer.

• Institution name — the public name customers will see.
• Sector — banking, healthcare, education, manufacturing, research, autonomous platforms, public sector.
• Size — small / mid / large; specifics if you're comfortable sharing (employees, sites, jurisdictions).
• Country / region — useful for the EU-on-prem-data framing if applicable.
• Logo — optional; SVG preferred, ~200×60.
• Spokesperson — name + title of the person whose words go on the page.

Section 2

The use case.

Two paragraphs. What problem you're solving with Eldric, why an on-prem AI server was the right call (vs cloud, vs not solving it). The honest version — including what's still rough.

• The problem — what was the team trying to do before Eldric?
• Why on-prem — regulatory, data-sensitivity, latency, cost, vendor-control reasons.
• Why Eldric — what tipped the choice against the alternatives (AWS Bedrock, OpenAI direct, self-hosting another stack).
• Where it's still rough — the honest read. We publish this; it's more credible than the marketing version.

Section 3

The Eldric configuration.

Enough technical detail that another customer in the same sector can picture themselves running it. Avoid LAN IPs, internal hostnames, and anything else that would identify the deployment topology more than the institution wants.

• Tier — Free, Standard, Pro, Enterprise.
• Cluster shape — single-node / multi-node / edge nodes. Approximate node count.
• Hardware class — workstation / dept server / data-centre / mixed.
• Workers in use — Inference, Agent, Data, Comm, Science, Training, IoT, xLSTM — which ones, which models.
• Integrations — what connects to Eldric: existing databases, comm channels, IoT endpoints, identity systems.
• Scale — knowledge-base size, traffic profile (queries per day), document throughput.

Section 4

The outcome.

Two paragraphs. What's actually working. Specific metrics where you have them — attributed to the customer, not invented by us. What changed for the people using the system.

• Quantified outcomes — only if real and customer-attributed (e.g. "review time on standard contracts dropped from N hours to M according to the team's own audit").
• Qualitative outcomes — the user-experience read.
• Lessons — what would the team do differently if starting over.

Section 5 (optional)

The pull quote.

One sentence from the spokesperson, attributed by name + title. Used on the customer-stories landing page and possibly other pages on eldric.ai. Always reviewed before publication.

Review & publish

The cycle.

1. Customer fills the brief above and sends it to office@eldric.ai.
2. The Eldric team comes back within a week with a draft and 3–5 follow-up questions.
3. Customer reviews the draft, sends back edits.
4. Final draft goes back to the customer for sign-off.
5. Story goes live on /customers/.

If the customer changes their mind at any stage — the draft, the metrics, the spokesperson, the whole thing — we walk it back. Nothing on this page exists without the customer it describes being comfortable with it.