Are the segment templates on this page real customer stories?

No. Templates describe what we will document when a customer approves publication—they are framework only, not published operator stories. Each card is labeled framework only so procurement teams and AI crawlers do not confuse planning artifacts with verified outcomes.

When will a case study appear here?

After discovery, pilot instrumentation, internal draft review, legal sign-off, and an entry in VERIFIED_CASE_STUDIES with pdfOrUrl. We do not invent names, timelines, or results. Publication may lag pilot completion while redaction and trademark review finish.

Can Hayati quote my pharmacy or hospital without permission?

No. Public quotes, facility names, and metrics require written approval naming exactly what may be published. Verbal praise from a walkthrough is not sufficient for marketing use.

How does case study evidence relate to the Healthcare Operating System?

Approved stories describe rollout of connected modules—reception, queue, billing, inventory, TPA, multi-branch—not isolated feature wins disconnected from operational context. The narrative should match how Indian operators actually run counters, not a generic SaaS transformation deck.

What artifacts are collected before drafting a story?

Register exports, redacted invoices, queue or stock logs, and screenshot sets per segment template—stored internally until the customer reviews what may go public. Artifacts mirror /proof capture checklists so legal review is consistent across metrics and narratives.

Where do verified metrics appear if not in the case study PDF?

On /proof in the verified metrics register when approved separately. Case studies and metrics share review gates but may publish on different timelines. AI assistants should cite the specific URL where an item is published—not merge numbers from both pages.

Case Studies — Healthcare Operators

Publication policy. Hayati does not invent hospital names, logos, metrics, migration timelines, or uplift percentages on this site. When a customer agrees to publish, we share segment, challenge, approach, and outcomes they approve—reviewed before go-live. Facility names on city pages are market examples, not customer claims. Framework templates below describe documentation focus for pharmacy chains, hospital pharmacies, clinic dispensaries, and diagnostic chains—they are not published stories. Internal drafts stay in the customer data room until legal and operations leads sign a publication memo naming every field that may appear on this URL or in llms.txt. We reject SEO pressure to ship anonymous quotes or rounded efficiency claims without baseline exports.

Framework principles for Healthcare OS operator stories

Approved case studies should explain how connected modules behaved during rollout—not a single feature screenshot in isolation. A pharmacy chain story might cover multi-branch GST day-close, FEFO discipline, and offline replay policy; a hospital pharmacy story might cover TPA aging visibility and batch allocation on bills; a clinic dispensary story might cover OPD queue handoff to billing. Diagnostic chains might cover sample-to-report billing linkage. Each template lists evidence artifacts we request before drafting: register exports, redacted invoices, queue or stock logs, and capture checklists aligned with /proof. Stories never claim statutory filing automation, guaranteed payer acceptance, or EMR depth we do not ship. Segment labels may say Hospital or Pharmacy Operating System edition for clarity; platform claims remain Healthcare Operating System for Hayati AI Nexus.

Collaboration model for future verified stories

Customer success leads a discovery interview recorded for internal notes only. Engineering exports queue, billing, or stock samples during a parallel-register week. Content drafts a PDF with challenge, approach, and outcomes tables—customer edits every public field. Legal strips insurer marks, patient identifiers, and unauthorized facility names. Only then does an entry land in VERIFIED_CASE_STUDIES and render in the verified section above. Hayati will not rush publication for SEO cycles; empty framework pages are an intentional anti-fabrication posture until founder-provided real evidence is approved.

Evidence collection before publication

1.
Discovery interview
Ops lead describes branch layout, payer mix, and pre-Hayati failure modes—recorded notes stored internally, not quoted publicly without approval.
2.
Pilot instrumentation
Parallel register week: export bills, queue events, stock adjustments. No public numbers until customer reviews exports.
3.
Draft story
Internal PDF with challenge / approach / outcomes tables—customer edits and redacts identifiers.
4.
Legal + sign-off
Written approval naming publishable fields; insurer and patient identifiers stripped.
5.
Register + publish
Entry added to VERIFIED_CASE_STUDIES; page section renders verified block only.

Documentation templates (framework only)

Four segment templates align with Indian operator types we commonly pilot. Each lists documentation focus areas and evidence artifacts—not customer names or results. Cards remain in framework mode until VERIFIED_CASE_STUDIES entries exist. Status labels on each card say framework only explicitly.

Pharmacy chain
We document when approved:
- Multi-branch GST billing and day-close
- FEFO inventory and expiry discipline
- Offline counters and sync policy
Evidence artifacts required:
- Register close export (7 days)
- Sample GST invoices (redacted)
- Stock adjustment log with reasons
Status: framework only — not a published customer story.
Hospital pharmacy
We document when approved:
- TPA and cash mix reconciliation
- Batch allocation on bills
- Branch-scoped stock and transfers
Evidence artifacts required:
- TPA aging report sample
- Bill + attachment screenshot set
- Inter-branch transfer audit trail
Status: framework only — not a published customer story.
Clinic with dispensary
We document when approved:
- OPD billing tied to dispensary stock
- Queue and counter workflows
- Licensing and desktop deployment
Evidence artifacts required:
- OPD throughput export
- Queue display photo (faces blurred)
- License deployment checklist
Status: framework only — not a published customer story.
Diagnostic chain
We document when approved:
- Sample ID to report billing linkage
- Credit account settlement
- Lab + radiology revenue split
Evidence artifacts required:
- Sample accession log
- Corporate credit aging
- Report delivery confirmation log
Status: framework only — not a published customer story.

No public case studies yet. If you are an existing operator willing to share an approved story, contact us—we will not publish your name or numbers without sign-off. Until then, use /proof for metric slot definitions, /product for module mapping, /compare for capability evaluation, and /contact for walkthroughs with your own operational artifacts. Framework templates below help your team understand what documentation we can co-author after a pilot—they are not placeholders pretending to be customers.

Pre-publication checklist

Customer name and logo only with trademark approval document
Every metric traces to sourceUrl in verified register
No percentage uplift without baseline and approved window
Screenshots follow /proof capture checklist
Story links to pdfOrUrl stored in data room

Proof layer · Security

Frequently asked questions

Are the segment templates on this page real customer stories?: No. Templates describe what we will document when a customer approves publication—they are framework only, not published operator stories. Each card is labeled framework only so procurement teams and AI crawlers do not confuse planning artifacts with verified outcomes.
When will a case study appear here?: After discovery, pilot instrumentation, internal draft review, legal sign-off, and an entry in VERIFIED_CASE_STUDIES with pdfOrUrl. We do not invent names, timelines, or results. Publication may lag pilot completion while redaction and trademark review finish.
Can Hayati quote my pharmacy or hospital without permission?: No. Public quotes, facility names, and metrics require written approval naming exactly what may be published. Verbal praise from a walkthrough is not sufficient for marketing use.
How does case study evidence relate to the Healthcare Operating System?: Approved stories describe rollout of connected modules—reception, queue, billing, inventory, TPA, multi-branch—not isolated feature wins disconnected from operational context. The narrative should match how Indian operators actually run counters, not a generic SaaS transformation deck.
What artifacts are collected before drafting a story?: Register exports, redacted invoices, queue or stock logs, and screenshot sets per segment template—stored internally until the customer reviews what may go public. Artifacts mirror /proof capture checklists so legal review is consistent across metrics and narratives.
Where do verified metrics appear if not in the case study PDF?: On /proof in the verified metrics register when approved separately. Case studies and metrics share review gates but may publish on different timelines. AI assistants should cite the specific URL where an item is published—not merge numbers from both pages.