Store · Commerce

Behind every price,
three tiers of truth.

The store isn't a product page. Clinical care and supplements share the same cart, the same register. The price a patient sees is the tip of a layered system built on atomic configuration, operational bundling, and a commercial surface, with AI handling the messy parts at checkout.

The Problem

Every sale ended with a manual payment link sent over WhatsApp.

The sales process was a phone call. A lead would come in through marketing, someone on the team would call them on WhatsApp, walk them through whatever programs were on offer, and follow up two or three times until they were ready to buy. At that point a payment link got generated and sent manually. Nothing was self-serve, nothing was automated, and the catalog existed only in what the sales team chose to say during the call.

That model works at low volume. It breaks when the client base starts to scale. Follow-ups slipped when no one remembered to make them. Pricing had no single source of truth. A ninety-day program was a different number depending on who quoted it and when. Renewals had to be initiated manually every time, for every client. Orders were tracked in someone's head or not at all.

The goal wasn't to remove the personal touch. It was to build a system that handled the structure so the team had more room to actually be personal.

Commerce lifecycle
End-to-end · atomic to fulfilled
Atomic product · service Room bundle Store Item tax · pricing Checkout ✦ AI fills Fulfilled delivered · active
The Model

Four layers. One chain from atom to storefront.

Every product and service starts as an atom, a raw definition holding its native attributes. Atoms bundle into Room Configs, which hold delivery guidance and become the actual offering. Room Configs get a commercial sticker at the Store Item level, then surface on the Store Front for purchase. When payment clears, the relevant Room Configs fire automatically and fulfillment begins.

Construct model · Store Management instantiation
Atom UNIT Text · Images Dimensions · Pricing Length · Fulfillment The base unit. Attributes set here via the product or service configurator. Room Config OFFERING Bundles atoms Delivery guidance Fulfillment rules Atoms combined into an offering with delivery and fulfillment guidance. Store Item SHELF Room Config ref Sticker pricing Batch config A commercial sticker placed on the Room Config. What the storefront shows. Store Front STOREFRONT Listed store items Customer catalog Cart + checkout Store Items surface here. Purchase triggers relevant Room Configs to run.
How it wires together · build to fulfillment
Atom attributes configured Room Config bundled offering Store Item commercial sticker Store Front listed for purchase customer purchases Customer Purchases cart checkout · Store Front payment confirmed Payment Confirmed purchase complete · order locked room configs activate Room Configs Fire fulfillment begins · delivery · access granted Atoms and Room Configs both hold fulfillment info. Both activate automatically on confirmed payment.
01 · Atomic Configuration

Every product and service starts at the atomic level.

Before anything reaches the store, it gets configured as a sub-offering, the source of truth. This is where the list price, delivery type, duration, tax codes, geo-restrictions, and fulfillment rules live. Products and services each have their own configuration surface but share the same atomic model. Everything downstream reads from here.

Product configuration — description, attributes, images, dimensions, and weight
Configuring a product: description, SKU, images, and physical specs in one atomic record

What gets configured at this level

Products

Physical goods or digital deliverables. SKU, inventory unit, tax code, and fulfillment method all sit at this level. The store item inherits and never overwrites them.

Services

Description, delivery modules (video session, live Q&A), images, and tiered pricing go into a single service record. Duration and operational T&Cs are set here, not downstream.

02 · Room Config to Store

Products and services bundle into a room. The room gets a commercial skin.

Room Config is the operational unit. It groups sub-offerings into a sequence, the clinical pathway or the service program. Once the room is configured, a Store Item wraps it in a commercial layer: the active price, marketing copy, regional overrides, and T&Cs. That Store Item goes on the store.

The golden rule: fulfillment lives at the atomic level. The store item inherits it and never owns it.

02 · atomic to commercial
Product atomic sub-offering Service atomic sub-offering Room Config Operational unit · bundles sub-offerings Store Item Commercial layer active price · tax · T&C · regional overrides published to store
03 · Checkout & AI Fulfillment

AI fills everything at checkout except the payment.

When a patient checks out, each item in the cart is handled at the atomic level, so the system reads the sub-offering to know what gets delivered, how, and to whom. Before payment is captured, the AI fills all the fulfillment information: who the service is for, what slot to schedule, where delivery goes, and any collection specifics. The patient only needs to pay.

03 · checkout sequence
Cart clinical + commerce items ✦ AI Fulfillment who · what · where · when all except payment Payment
04 · Store Front to Checkout

Browse and buy from inside the treatment room.

The store panel sits alongside the patient's chat, records, and meal plan. A single cart can hold items meant for more than one person, and each one checks out with its own fulfillment.

Amura store front with recommended products and best sellers
Checkout for
multiple people
Checkout screen with separate orders and fulfillment for Sarah Mitchell and James Turner in one cart
Store · Checkout

One cart, multiple offerings, ordered for multiple people. Sarah gets a home delivery and a lab visit at one address, James gets two deliveries and a lab visit at another, and both clear in the same checkout with their own fulfillment intact.

05 · Post-Payment Fulfillment

Products ship. Services activate. The room config runs.

Once payment clears, the system splits the cart at the atomic level and handles each item on its own terms. Physical products get dispatched to the confirmed delivery address. Services activate via the room config that was attached at configuration, so the session, the Q&A, and the clinical program all spin up on their own. No manual trigger needed.

05 · post-payment
Payment Confirmed Products Delivered Services Room config runs each item handled at atomic level
Outcomes

The manual work went away. The relationships stayed.

Before
  • Every sale initiated through a manual WhatsApp call
  • Pricing inconsistent, different quotes per rep, per call
  • Renewals tracked and triggered manually for each client
  • No self-serve path from discovery to purchase
After
  • Full catalog on a store front, self-serve discovery and checkout
  • CPQ engine calculates price dynamically, single source of truth
  • Subscription renewal in one tap, automated across all active clients
  • Clinical onboarding and purchase unified into one flow
4-layer
Catalog architecture
atomic to storefront
CPQ
Dynamic pricing
zero manual overrides
1-tap
Subscription renewal
across all active clients

"Every payment used to come in and someone had to match the transaction ID manually, confirm it, then go trigger the onboarding. A separate step every time. Now the store handles all of it. Payment clears, the patient is in, the room opens. We went from fifteen leads a day to five hundred and fifty-two on a single day in April."

Finance Team