Your product ships updates twice a week. The button that was on the left is now on the right. The API endpoint that was /v1/users is now /v2/users. The feature you told a customer about on Monday doesn't exist the way you described it by Thursday.

Your knowledge base is perpetually 3 days behind. Your canned responses reference UI elements that have moved. Your agents are learning the product at the same speed as your users.

This is support for a beta product, and it's chaos.

Why Beta Support Is Uniquely Hard

In mature product support, the product is stable and the documentation is current. Agents learn the product once and make minor adjustments over time. The answers to common questions stay the same for months.

In beta support, everything is a moving target. The agent's mental model of the product expires weekly. The screenshots in the knowledge base are from last sprint. The answer to "how do I export data?" changed yesterday because the engineering team reorganized the settings menu.

Customers are more tolerant (they signed up for a beta, they expect rough edges) but also more confused (every update changes something, and the changelog doesn't cover everything).

The Minimum Viable Documentation Strategy

Don't write full documentation during beta. It'll be wrong within a week. Instead, maintain a living document with two sections:

"What changed this week." A simple bulleted list of user-facing changes. Not a changelog with version numbers. A human-readable list: "Export button moved from Settings to the top toolbar." "New filter options on the reports page." "The /v1/users endpoint is deprecated, use /v2/users." Update this document with every deploy.

"Known issues." Everything that's broken and you know it. "CSV export sometimes includes a blank row at the end." "The dashboard loads slowly with more than 1,000 records." "OAuth login with Google occasionally fails on Firefox." Be specific. Include workarounds when they exist.

These two documents are your entire knowledge base during beta. They take 15 minutes per deploy to update. And they prevent 50% of beta support tickets because users can check "what changed" and "known issues" before contacting you.

Agent Onboarding During Beta

Don't give beta support agents a training manual. Give them a Slack channel and a demo environment.

The Slack channel (#product-updates or #beta-changes) gets a post from engineering with every deploy. It describes what changed in user-facing terms. Agents read it and ask questions. This is real-time documentation that stays current because it's generated with each change.

The demo environment lets agents try every new feature before customers encounter it. "The new filter was added yesterday. Before you open the queue, spend 5 minutes playing with it so you can help customers who ask about it."

This approach replaces traditional training (which goes stale during beta) with continuous learning that matches the product's change velocity.

The "I Don't Know" Permission

In mature support, "I don't know" is a last resort. In beta support, it should be a common and acceptable response.

"I'm not sure about that feature, it was just updated yesterday. Let me check with the team and get back to you within an hour." This response is honest, sets a timeline, and acknowledges the reality of a rapidly changing product.

Customers prefer an honest "I need to check" over a confident wrong answer. The confident wrong answer (based on last week's product state) creates a worse experience than the honest acknowledgment of uncertainty.

Give agents explicit permission to say "I don't know" during beta. The psychological safety of not needing to have every answer reduces stress and improves response quality.

Using AI During Beta

AI classification still works during beta, because the customer's intent doesn't change even when the product does. "How do I export data?" is the same intent whether the export button is in Settings or in the toolbar. The classification is stable. The response content needs to update.

Configure Supp's auto-responses to link to the "what changed" document rather than hardcoded instructions. "Export is available from your dashboard. For the latest instructions (our UI updates frequently in beta), see our current guide: [link]."

This approach makes the auto-response durable across product changes. The linked document gets updated with each deploy. The auto-response stays the same.

For beta-specific intents ("is this a bug or a feature?" "when will [thing] be fixed?" "why did [thing] change?"), configure responses that set expectations: "You're using our beta product, which changes frequently. Here are the latest updates: [link]. If the issue persists after checking the updates, reply and we'll investigate."

The Beta Graduation

Beta ends when your support team can answer most questions from documentation that hasn't changed in 30 days. That's the operational definition of "stable enough for general availability."

If your agents are still learning the product alongside users, you're still in beta, regardless of what your marketing page says. And your support experience will reflect it.

The transition from beta support to GA support is the transition from "we're all figuring this out together" to "we know how this works and we'll teach you." That transition requires stable documentation, trained agents, and a product that doesn't reorganize its UI every Thursday.

Until then, embrace the chaos. Keep the "what changed" doc current. Give agents the demo environment. And remember that your beta users chose to be on the bleeding edge. They'll tolerate rough support if you're honest about the product being rough too.