Define the baseline
Document the previous workflow, time period, data source, and known limitations.
Customer outcomes should be attributable, reviewable, and real.
Stelaah will not publish a fictional customer story or an unsupported improvement percentage. This page explains how participating customers can document their workflow and approve every public claim.
Measure the change
Use the same definition and comparable operating period after implementation.
Review every claim
The participating customer confirms the wording, evidence, and publication permission.
A publishable case study needs more than a happy quote.
The goal is to help another buyer evaluate fit, not to make a customer sound unusually perfect.
Choose a specific workflow
Focus on a bounded change such as inquiry response, approval time, invoicing latency, project visibility, or administrative effort.
Preserve the baseline
Record the period, data source, sample, exclusions, and operational conditions before introducing the new workflow.
Measure comparable results
Use the same definitions after adoption and distinguish measured results from the participant's interpretation.
Give the customer final approval
Confirm the company description, names, quotes, screenshots, numbers, limitations, and publication channels.
Every customer story must carry its evidence with it.
These fields make the operating context, measurement, permission, and limitations inspectable.
Company and operating contextPublish the approved company name or stated anonymity, industry, location where relevant, team size, client type, service model, and implementation scope.
Previous workflowName the systems, manual steps, owners, recurring problem, baseline period, source data, exclusions, and known limitations.
What moved into StelaahList the exact records and workflows adopted, the retained specialist systems, the implementation dates, and the people involved.
Measured changeShow the metric definition, comparable before and after periods, sample size, calculation, source, and uncertainty. Do not turn an observation into a measured result.
Customer voicePublish quotes only with the speaker's role, documented permission, approved wording, date, and any confidentiality boundary.
Screenshots and evidenceUse approved real product or workflow captures with private information removed. Link claims to the source record or methodology reviewers can inspect.
Authorship and reviewName the Stelaah author and reviewer, the customer approver, publication date, latest verification date, corrections policy, and conflicts or incentives.
Limits and transferabilityState what changed, what did not, material external factors, and why another organization should not assume the same result.
What Stelaah will and will not publish.
Trust grows when the boundary around a claim is visible.
Measured resultA value calculated from an identified source, period, definition, and sample.
Customer observationA clearly attributed statement presented as the participant's experience, not universal fact.
Stelaah inferenceAn interpretation labeled as Stelaah's analysis and separated from measured evidence.
Not acceptableInvented customers, composite quotes presented as real, unverified percentages, or screenshots containing fabricated performance.
Verified customer evidence, answered.
Are there customer results published here yet?
Not yet. Stelaah will add case studies only after the participating customer reviews and approves the evidence and wording.
Can a customer participate anonymously?
Research participation may be anonymized, but a public case study must still have documented internal consent and clear limits on what can be disclosed.
Will Stelaah guarantee the same result for another company?
No. Case studies describe one operating context and do not guarantee another customer's outcome.
Help document a real client-work improvement.
Contact Stelaah to discuss a measured, permissioned customer story.