A sale pushes a large share of your support questions into a few hours, and many of them are the same dozen questions about discount terms, shipping cut-offs and returns. An AI agent that answers from your content can take many of those, but only if the sale terms are in its content before the sale starts, and only if the system around it has been sized for the peak. This post is a preparation checklist for LayBuild: what to write, what to configure, which limits apply, and how to test before real customers arrive. We do not quote throughput figures, because they depend on your LLM provider, your deployment and your traffic shape. The limits below are the configured defaults; the numbers that matter are the ones you measure.

What customers ask during a sale

Sorting the questions by what the AI can answer makes the rest of the plan obvious.

The AI can answer questions about written policy: which products are in the sale, when it starts and ends (with the time zone), whether codes stack, the last order date for delivery before a holiday, whether sale items can be returned, how long refunds take. These have one correct answer that you can write down in advance.

The AI cannot answer questions about live state: whether an item is in stock right now, where a specific order is, why a specific payment failed. LayBuild's API tools call an HTTP endpoint with the defaults you configure after the answer is generated; they do not take an order number from the customer's message and look it up. For these, point customers to your order tracking page in your content, and route the rest to people.

Put the sale terms in a pinned document

Retrieval can miss. For information every sale conversation depends on, do not rely on it. Pinned documents are injected into every prompt, capped at 4,000 characters per document and 12,000 characters across all pinned documents.

Write one short sale document and pin it:

  • Start and end date and time, with the time zone.
  • What is included and excluded, by category or collection, not product by product.
  • How discounts apply: automatic or code, whether they stack, minimum order values.
  • The shipping cut-off for any delivery promise, and what happens to orders after it.
  • The returns policy for sale items, if it differs from your normal one.

Keep it under the 4,000-character cap. If terms change during the sale (an extension, a sold-out category), update the pinned document straight away, because the AI will keep answering from the old version until you do. Unpin it when the sale ends, or customers will be told about a discount that no longer exists.

Add Q&A pairs for shipping and returns

Shipping and returns questions arrive in many phrasings: "will it arrive by Friday", "can I send it back if it doesn't fit", "do sale items have free returns". Q&A pairs have their own retrieval leg, so a handful of pairs with the phrasings your customers actually use covers the wording gaps that document retrieval misses.

Look at the Knowledge Q&A page's list of most frequently asked customer questions from your last sale or busy period, and turn the top shipping and returns questions into pairs. Review them after the sale; a pair that says "orders placed by Thursday arrive by the weekend" is wrong the following week.

If your help pages about shipping or returns changed for the sale, add their URLs again. LayBuild fetches listed URLs when you add them and does not re-sync on a schedule.

Check your plan's conversation allowance

LayBuild plans include a monthly allowance of conversations: 1,500 on Starter, 8,000 on Pro and 20,000 on Premium. A conversation is a chat thread started in the billing period, however many messages it contains. The usage view in your account shows how many you have used.

Estimate a sale month with your own numbers. As an illustration only: if a normal month brings 2,000 conversations and you expect the sale week to add as many again, plan for 4,000, which is within Pro. If your estimate is close to or past your plan's allowance, talk to us before the sale rather than during it.

Know the rate limits and queues in the path

Several limits sit between a shopper and an AI reply. They protect the service from abuse, and during a spike they are also where legitimate traffic can get turned away. These are the defaults in the code.

text
shopper
  |
  v
widget session : per IP: 60 new sessions / minute (configurable per widget)
  |
  v
Socket.io      : per IP: 30 connections / 60 s; per user: 20 messages / 60 s
  |
  v
message queue  : per API process: 8 AI replies at once, up to 2,000 waiting
  |
  v
LangGraph run  : capped at 60 s per reply
  |
  v
LLM provider   : your provider's own rate limits, with failover to the next provider

The widget session limit is set per IP address. Shoppers who share one public IP, such as people on the same office network or behind a mobile carrier's shared addresses, share that budget. You can raise it in the widget settings. Most HTTP routes also sit behind a global limit of 300 requests per minute per client, backed by Redis when Redis is available.

The message queue is in memory, per API process. It runs AI replies with a default concurrency of 8 and holds up to 2,000 queued messages. Replies within one conversation run in order, one at a time. If the queue is full, the customer gets a holding message saying their inquiry was received, and that message is not re-queued later. Nobody is automatically notified. That is the failure mode to size against: at your peak, the queue should drain faster than it fills.

If you self-host, all of these are environment variables (MESSAGE_QUEUE_CONCURRENCY, MESSAGE_QUEUE_MAX_SIZE, SOCKET_MSG_RATE_LIMIT, SOCKET_CONN_RATE_LIMIT and their window settings, AGENT_RUN_TIMEOUT_SECONDS). Raising concurrency only helps if your LLM provider will accept the extra parallel requests. The provider's rate limit is often the tightest constraint, so check your provider's limits for the model you use, and configure a second provider so the circuit breaker has somewhere to fail over to.

Staff the handoffs

Some sale conversations will go to people: payment failures, orders that did not arrive, customers who ask for a person. Plan for them explicitly.

  • Decide who answers handoffs during the sale hours and make sure each person has a seat with the AGENT, ADMIN or OWNER role.
  • Switch on ALLOW_HUMAN_HANDOFF if you want widget customers to be able to ask for a person. If it is off, edit the prompt so the AI does not promise a handoff that will not happen.
  • If you use WhatsApp, check the channel's handoff keywords. The defaults include "help" and "support", matched anywhere in a message, which during a sale can send a large share of WhatsApp conversations to people.
  • Keep the dashboard open during sale hours. Handoffs appear in the queue in real time; claiming a conversation is exclusive, so two agents will not answer the same customer.
  • Remember that conversations with no activity for 24 hours are closed automatically, including unclaimed handoffs. Clear the handoff queue before the end of each day of the sale.

Load test before the sale

A load test tells you where the first limit bites with your provider, your content and your deployment. Run it against a self-hosted staging copy, or talk to us before pointing load at the hosted service.

  • First, write a script that behaves like a shopper: start a widget session, open the socket connection, send one of your real sale questions, and wait for the reply. Use a spread of questions, including some that hit the fixed no-answer reply and some that trigger a handoff.
  • Next, spread the virtual shoppers across several source IPs, or raise the per-IP limits in staging, or you will measure the rate limiter rather than the system.
  • Then ramp gradually and record, at each step: time to the first streamed token, time to the complete reply, the number of holding messages from a full queue, and any rate-limit errors from your LLM provider.
  • Finally, repeat the test with your primary LLM provider switched off, to confirm that failover works and to see how the fallback provider behaves under the same load.

Use the provider and model you will use on the day. A load test against a different model or a higher rate-limit tier tells you little about the sale.

After the sale

Unpin the sale document. Review the Q&A pairs you added and remove or update the ones tied to sale dates. Read a sample of transcripts from the busiest hour, especially the ones that ended in the fixed no-answer reply or a handoff, and turn the recurring gaps into content for next time. LayBuild's learning loop may also have published some sale-specific answers into the knowledge base on its own; search for them and remove any that will be wrong once the sale is over.

Related reading