Refills Custom OMS ↔ Lorikeet — Integration POV & Discovery Plan

• Shape of the integration. The custom OMS is the system of record. Lorikeet spans it — receiving patient conversations from in-app messenger and email, reading what it needs from the OMS (patient profiles, orders, prescriptions, dosing schedules), and either resolving the ticket or escalating cleanly. During migration, Lorikeet also reads from Bask and Telegra for patients still on those platforms.
• Custom OMS has open APIs. The team owns and hosts the database. APIs are under active development, which means we can co-design the surface Lorikeet needs. This is a strength — we can request the exact endpoints and response shapes that make workflows efficient, rather than working around a third-party's limitations.
• Two telehealth platforms, one agent. Some patients are on Bask, others on Telegra. Lorikeet's workflow layer handles the routing — identify which platform the patient is on, call the right API, present a unified experience. The patient never knows the difference.
• Channel consolidation is a goal. Refills wants to move off Gorgeous and centralise everything — chat, email, ticketing — under one roof. Lorikeet's chat widget and native ticketing can replace both Gorgeous and the existing FAQ bot (MyAsk AI).
• Phase 1 targets four use cases. Order status, subscription management (date changes, cancellations), dosage change requests, and issue reporting (damaged medication, reshipments). These cover ~60% of ticket volume.

The custom OMS is the system of record. Lorikeet is the agent that sits between patients and the OMS.

What this means for scope:

• Custom OMS owns patient data, orders, prescriptions, and dosing schedules. Lorikeet reads the OMS to answer questions and writes to it to take actions (reschedule shipments, submit dosage review requests, process reshipments). Since Refills owns this system, we can co-design the API surface for optimal Lorikeet consumption.
• Bask and Telegra are the underlying telehealth platforms that manage clinical workflows, pharmacy fulfillment, and provider networks. During migration, some patients still live in these systems. Lorikeet routes to the right platform per-patient.
• Gorgeous is the current email ticketing system. In Phase 1, Lorikeet integrates with Gorgeous as an agent seat. In Phase 2, Lorikeet's native ticketing replaces Gorgeous entirely.
• Stripe sits behind the OMS for billing. Lorikeet accesses it through the OMS API layer — no direct Stripe integration needed unless the OMS doesn't expose billing endpoints.

Why this framing lowers delivery risk:

1. The custom OMS with open APIs means no third-party API gatekeeping — we can move at Refills' engineering velocity, not a vendor's.
2. Channel consolidation into Lorikeet eliminates the current problem of duplicate tickets across messenger and Gorgeous.
3. Phase 1 is read-heavy. Most workflows need to read patient data and present it. The only writes are shipping date changes and reshipment requests — well-scoped, reversible actions.

Three integration surfaces, prioritised by patient volume and action frequency.

A. Custom OMS (primary — all patients)

B. Bask Health (legacy patients)

C. Telegra MD (secondary patients)

This is the hardest ticket in Refills' queue and the one Harrison flagged as highest-value. Here's how Lorikeet handles it end-to-end.

What this illustrates:

• Clinical safety is non-negotiable. The provider set a dosing cap. Lorikeet respects it. No amount of patient pushback changes the agent's behavior — the guardrail is deterministic, not a suggestion.
• The agent explains why, not just no. "Dr. Mitchell noted 7.5mg as your current ceiling due to the dizziness you reported" is more helpful than "I can't do that." It acknowledges the patient's frustration while holding the clinical line.
• Escalation to the provider is automated. Today this involves an agent switching between the CRM, a separate messaging tool, and possibly Slack to reach the doctor. Lorikeet does it in one API call.
• The whole thing takes seconds. A human agent spends 10-15 minutes on this. Lorikeet resolves it in the span of a conversation.

Omar flagged that the current AI is "over empathetic — it makes things a lot worse when somebody is frustrated." Lorikeet's approach is calibrated: empathetic enough to acknowledge the patient's position, firm enough to not waver on clinical guidance. And critically, it can't be socially engineered into changing its instructions the way a human sometimes can.

These are the data domains Lorikeet needs from the custom OMS to power the four target workflows. Reads are required for Phase 1; writes are phased and individually gated.

Matt asked directly: "Can we also integrate two platforms? Some of our customers are on Bask, some on Telegra. Is your platform dynamic enough to pull into both?"

Yes. Here's the routing pattern:

How this works in practice:

• The OMS is the identity layer. Every patient has a record in the custom OMS, even if their clinical data lives in Bask or Telegra. The OMS record tells Lorikeet which platform to query for the clinical details.
• Tool definitions are per-platform. Lorikeet's tool layer handles the mapping: "get order status" resolves to a different API call depending on whether the patient is Bask or Telegra, but the workflow logic is the same.
• This pattern is not new for us. Steve described it on the call: "We build a bundle of logic that first finds the right system for the right patient and then goes and gets the information for that system." We run this pattern in production for multiple subscribers with fragmented backends.

Important scoping question: Does the custom OMS already proxy data from Bask and Telegra? If so, Lorikeet only ever needs one API surface. If not, we integrate with all three independently — more work upfront but still well within the pattern we run today.

Phase 0 — Pre-work (parallel with kickoff)

• BAA signed (HIPAA compliance, PHI handling agreement).
• OMS API documentation shared — or a live walkthrough of existing endpoints with Mansoor's team.
• Bask and Telegra API credentials provisioned for Lorikeet's test environment.
• Technical contact named on each side: OMS API owner (Mansoor or delegate), Lorikeet FDE.
• Sample ticket data — real ticket shapes (redacted) so we design workflows against actual patient language, not hypotheticals.
• Gorgeous API key or Connected App provisioned for Phase 1 email integration.

Phase 1 — Core four workflows + Gorgeous integration

Goal: Lorikeet resolves the four highest-volume ticket types end-to-end.

• Order status lookup. Read order, shipping, and tracking info from OMS. Low complexity, high volume.
• Subscription management. Date changes, pauses, cancellations. Read + write against OMS subscription endpoints.
• Dosage change requests. Read prescription and dosing schedule. Apply clinical guardrails. Submit review request to provider. Human-in-loop on all dosage actions.
• Issue reporting. Damaged/cloudy medication. Create issue report. Trigger reshipment with guardrails (max 1 per customer before escalation).
• Channel: Lorikeet integrates with Gorgeous as an agent seat for email. In-app messenger routes to Lorikeet via SDK or API.
• Escalation: Tickets Lorikeet can't handle go to the human queue in Gorgeous. No change to human agent workflow.

Success metric: 50-70% resolution rate on the four target workflows. Measured by tickets fully resolved without human intervention.

Phase 2 — Channel consolidation + expanded actions

• Replace Gorgeous with Lorikeet's native ticketing. Email intake directly into Lorikeet. Eliminates duplicate tickets across messenger and email.
• Lorikeet chat widget replaces MyAsk AI and the in-app messenger. Single widget, single system of record.
• Billing actions: refunds, payment method updates, plan changes (via OMS + Stripe).
• Retention workflows: when a patient wants to cancel, Lorikeet triages the reason and either resolves or routes to a retention specialist.
• Reshipment guardrails tightened: based on Phase 1 data, move from human-in-loop to Lorikeet-managed with hard limits (Matt's concern about gaming).

Phase 3 — Proactive outbound + sales

• Check-in calls. Outbound voice or SMS for the 3-month questionnaire Harrison mentioned. AI handles the nine questions, flags issues, routes complex cases to a human.
• Re-engagement campaigns. Contact lapsed patients, identify reason for drop-off, offer tailored re-engagement (not blast discounts — Steve's point).
• Lead qualification. AI triages inbound interest, qualifies against eligibility criteria, routes hot leads to the sales team.
• Promotional awareness. When marketing runs a promotion, Lorikeet knows about it and can answer questions or apply offers — solving Harrison's concern about CX being out of sync with marketing.

These aren't bespoke for Refills — they're how we deploy anything touching patient data and prescription medication.

1. No clinical advice. Lorikeet does not recommend dosages, diagnose symptoms, or suggest treatment changes. Any clinical question escalates to a human or routes to the provider. This is a hard boundary, not a prompt instruction.
2. Dosing caps are law. If a provider has set a dosing ceiling, Lorikeet cannot override it regardless of patient pressure. The guardrail reads the provider note and enforces it deterministically.
3. Reshipment fraud protection. Matt flagged the gaming risk: "If it's AI, they just automatically do the process." Our approach: hard limit on reshipments per patient (e.g., one per 90-day cycle). Beyond that, escalate to human. Lorikeet checks history before actioning — not after.
4. Discount and pricing guardrails. Harrison flagged: "I could see people switching pricing, giving a 30% discount, but having a threshold of $169 — do not go below that." Lorikeet enforces price floors and discount ceilings as deterministic guardrails, not AI judgment calls.
5. PHI minimisation. Only the fields a workflow actually needs are passed to the LLM context. Full patient charts are never surfaced. Audit trail of every field accessed.
6. Patient identity verification. Email match (current method) before any data is surfaced. Can upgrade to DOB, verification code, or multi-factor based on Refills' preference.
7. Message checks. Inbound patient messages are scanned for self-harm language, medical emergency indicators, and threats. These bypass all workflows and escalate immediately.
8. Concierge checks. Before Lorikeet sends any response, a deterministic layer reviews it for: medical claims, dosing recommendations, off-label suggestions, and tone calibration (Omar's concern about being "over empathetic").
9. AI-generated attribution. Every Lorikeet action is tagged and logged. For audit, compliance, and QA. Matches what we do for all regulated subscribers.

What we'd want to resolve together on the first integration call, grouped by who'd typically answer each.

1. Integration scoping call (60-90 minutes) with: Mansoor + OMS engineering, Harrison + Omar from CX, and a compliance representative if available. Lorikeet side: Forward-deployed engineer and product manager.
2. Pre-read: This document, plus whatever OMS API documentation Mansoor can share in advance (his request: "Send it ahead of time so we can gather those responses").
3. Agenda: Walk through the discovery questions. Leave with a clear picture of what endpoints exist, what needs to be built, and a Phase 1 scope both sides agree on.
4. Output: A Phase 1 statement of work with named workflows, named API endpoints, named success metrics, and a target go-live date.

The two things that most accelerate launch:

• OMS API access (even a partial spec or Postman collection) so we can start mapping tools.
• A signed BAA so we can work with real ticket shapes instead of synthetic data.

Mansoor's ask was clear: "The most important thing is cost as well as the timeline. We want to know before we actually do anything." The scoping call gives us what we need to provide both with confidence.