Skip to main content
Every customer interaction starts with an inbound text. From there, the bot identifies the sender, personalizes the response, and routes the request through the appropriate tool, whether that’s a catalog lookup, an order recall, or a support answer. Understanding this flow helps you anticipate how the bot will behave and where it will ask your team to step in.

​
Conversation Flow

1

Customer texts your Twilio number

The inbound message triggers a webhook to your Fit4Life OS backend. The system receives the sender’s phone number and message body.
2

Bot identifies the sender

The bot looks up the phone number in your customer database. If it finds a match, it retrieves the customer’s profile, order history, and archived conversation threads.
3

Bot greets by first name

Recognized customers are greeted by their first name. This signals to them that the system knows who they are and that their account is accessible.
4

Bot handles the request with tools

The bot interprets the customer’s intent and calls the appropriate tool, catalog search, category browse, order lookup, or FAQ response, then replies over SMS.
When a customer asks a broad question like “what do you have?” or “what’s on the menu?”, the bot routes the query by category and returns a structured list of available product categories. From there, the customer can drill into a specific category or name a product directly.
  • Named category: if the customer asks about a specific category (for example, “what peptides do you carry?”), the bot queries your catalog and returns all active products in that category with their prices.
  • Specific product: if the customer names a product, the bot runs a search and returns the matching result, including description and price.
All catalog responses are pulled from the product catalog through tools on every request. The bot does not cache or guess prices, what the customer sees is exactly what is in the catalog.
The bot will not list the menu from memory or claim a list is “complete” or “the full menu” unless it just pulled that list from the catalog in the same reply. If it is unsure it has covered everything, it offers to pull up a specific category rather than overstating. This prevents the bot from confidently listing an out-of-date or partial menu.

​
Reorder Flow

Reorders are the most common bot-assisted transaction. Here is how the full reorder sequence works:
1

Customer expresses reorder intent

The customer texts something like “reorder” or “I want my usual.” The bot recognizes the intent and looks up their most recent completed order.
2

Bot presents the last order with price

The bot replies with the items and total from the previous order and asks the customer to confirm. For example: “Your last order was [Product Name], $X. Reply YES to reorder.”
3

Customer confirms

The customer replies with a confirmation. This creates a pending_payment order record in your system and triggers the bot to generate a Clover invoice.
4

Bot sends the payment link

The bot texts the customer a secure link to the branded Fit4Life checkout page. The order remains in pending status until payment is received.
5

Payment commits the order

The customer enters their card on the checkout page (directly into Clover’s embedded card fields, so card data never touches Fit4Life servers) and Clover processes the charge. A succeeded charge immediately updates the order from pending to committed. The bot does not send a final confirmation message unless you have configured one.
A conversational “yes” alone does not charge the customer. Payment through the Clover link is the only commit trigger. This protects both you and your customers from accidental charges.
A customer can reorder their usual AND add extra menu items in the same request, for example “reorder my Retatrutide and add BPC-157 and GHK-Cu.” The bot quotes the combined total (the reorder priced from their history plus the added menu items at menu price) and, on a clear yes, creates a SINGLE order and sends a SINGLE payment link for the full amount. It never splits a reorder-plus-add into two separate links. Added items must be priceable on the menu. A brand-new dose-based item (like a first-time Retatrutide at a specific dose) cannot be added this way and is routed to a team member, but a dose-based item that is part of the customer’s own reorder is always fine. If a customer says they did not receive their link or asks you to resend it, the bot re-sends the SAME payment link for their open order. It never creates a duplicate order or a second charge, and it never tells a customer it is unable to resend. A payment link is always delivered as an actual working link in the message, the bot will not say “link sent” without attaching one.

​
Order status and post-purchase

A customer can ask “where’s my order?”, “did it ship?”, or “when will it arrive?” and the bot reports the fulfillment stage of their most recent committed order (for example “paid and being prepared” or “on the way”). For exact delivery times or clinic specifics it cannot see, it offers a team-member follow-up rather than guessing.

​
Referrals

After helping a happy customer, the bot may mention your referral program once and offer to have a team member set them up. It does not invent referral rewards or links, it routes interested customers to a human. This turns satisfied customers into word-of-mouth growth, which is especially valuable for out-of-state patients.

​
Order Gating

The bot enforces a strict gate between conversation and commerce. No order is ever committed based solely on what a customer says over SMS. The sequence is always: intent → pending order → payment link → completed payment → confirmed order. If a customer confirms but never pays, the pending order can be reviewed and cleared from your dashboard.

​
Memory and Recall

The bot maintains a conversation archive for each customer. When a new message arrives, the system retrieves relevant past threads and includes them as context for the current conversation. This means the bot can reference what a customer asked last week without requiring the customer to repeat themselves.
This is retrieval memory, the bot searches and surfaces past conversation snippets. It is not model retraining. The underlying Claude model does not learn from your customers’ conversations.

​
Unrecognized Senders

When a text arrives from a phone number that does not match any customer in your database, the bot applies a split policy:
  • Benign FAQs (hours, location, general program questions), the bot answers normally without requiring account identification.
  • Purchase intent: if an unknown number asks to buy something or place an order, the bot does not attempt to process it. Instead, it flags the thread in your Operations Inbox as a new lead and a human handles intake.

​
What the Bot Cannot Do

  • Access any customer’s data other than the customer who is currently texting
  • Reveal clinic financials, supplier costs, margin information, or internal business data
  • Place, confirm, or charge an order without first sending a Clover payment link
  • Provide clinical guidance, dosing questions, side-effect questions, and medical advice are always escalated

​
SMS Formatting

All bot replies use GSM-7 safe characters to ensure maximum carrier compatibility. If a response exceeds the standard SMS character limit, the bot splits it into multiple messages automatically so no single SMS is truncated by the carrier. Avoid configuring custom reply templates with Unicode-only characters (curly quotes, emoji, or accented characters not in the GSM-7 set), as these force messages into UCS-2 encoding and reduce the per-message character limit significantly.