Plans and included capabilities

Current subscription prices#

Compare the same billing interval across plans. Core at $39 per month on the yearly view means $468 collected for the year, rather than a $39 monthly charge. The equivalent comparison for Business is $119 and for Scale $599. A displayed saving is a comparison with twelve monthly payments, not a credit stored in your account. Before paying, read the annual total and tax in Checkout. If your company budgets in another currency, do not treat a card issuer's eventual conversion as a Reesponder price guarantee. Keep the provider receipt for the actual settled currency and amount.

Core: one website and capable support#

Core includes one website, 500 monthly conversation units and up to seven days of full transcript history. It includes website and custom Knowledge, page context, multilingual support and the same underlying intelligence as the higher plans.

A practical Core launch starts with one website and accurate sources: product or service descriptions, delivery or booking rules, returns, opening hours and ordinary contact details. Test a question with a known answer and one that the business cannot answer. This checks the Knowledge rather than a plan label. Seven days is the maximum full-history option, so assign someone to review customer issues before they expire. If your business only needs public answers and a clear contact fallback, configuring an order endpoint merely to demonstrate an unused feature is unnecessary. Choose a plan for the workflow you intend to operate.

Business: connected reads and team operations#

Business includes 2,000 monthly units, up to thirty days of full history, multiple websites, read-only Actions, human escalation, workspace team access and a setup session. Private reads still require a configured, tested and enabled integration.

For example, Business can expose an authorised order-status read while leaving refunds and address changes to staff. The integration still needs a suitable endpoint, a customer-ownership check, a current successful test and an enabled Action. Multiple websites share workspace capacity and can use appropriately scoped shared Knowledge; they do not each receive a fresh 2,000-unit allowance. Team invitations let authorised colleagues participate in that workspace. Keep membership review, Knowledge ownership and escalation destination current as the team grows. A setup session helps with configuration, but it does not replace your approval of what private records an endpoint may return.

Scale: confirmed writes and deeper measurement#

Scale includes 10,000 monthly units and up to ninety days of full history. It adds confirmed write Actions, journey/event measurement, custom identity and advanced branding choices. Customer-facing writes remain subject to execution checks and confirmation.

A useful Scale example is a confirmed support or return request whose exact submitted details appear in the Action card. Review the run result and business follow-up separately: a successful request record does not mean a refund was approved or a staff member replied. Journey events also require your server integration to report the actual event. A booking value associated with a conversation is not automatically causal revenue attribution. Assign owners for endpoint changes, event definitions and the longer history review process. The extra controls are valuable when someone maintains them; the plan itself cannot validate your business permissions or measurements.

Read the active usage period#

For paid subscriptions, the plan allowance renews in monthly usage periods even when the subscription is paid annually. Those boundaries follow the subscription's anchor, not necessarily the first day of the month. An annual purchase therefore provides monthly capacity across its paid term, rather than a single unrestricted annual pool. Top-ups belong to the usage period they credit and unused capacity does not roll into the next period. Review Overview's active period end as well as Billing's subscription renewal date: with yearly billing, they answer different questions. Manually granted access can have explicitly different allowances and validity dates.

Choose based on the workflow#

Make the choice in three passes. First, estimate conversation units using the actual counting rules, including unusually long support exchanges. Second, list the operations visitors genuinely need: public answers, authenticated reads or customer-confirmed writes. Third, identify the team's review period and measurement requirements. This avoids comparing plans by message count alone or assuming every visitor needs an integration. If you exceed your allowance only during an occasional campaign, compare expected top-ups with an ongoing larger subscription using the current offer. Confirm any actual plan-change timing and adjustments in the hosted billing portal before accepting them.

Build a demand worksheet before choosing#

Create a forecast with separate lines for ordinary enquiries, returning support cases and unusually long exchanges. Count the units those flows can require, rather than multiplying website page views by a subscription price. A visitor who views ten pages without submitting support does not use ten conversation units. A shopper who returns after the six-hour window or needs more than twenty AI answers can use more than one. Use a small authorised sample of real support patterns, recording time and answer count, without exporting unnecessary customer text. Include planned marketing campaigns and seasonal demand as separate scenarios so the team can see the assumptions behind the forecast.

For a multi-site business, add each site's expected demand into a workspace total. Do not allocate the entire Business allowance independently to every domain. Keep the normal forecast and a busy-month forecast alongside the monthly payment or annual-equivalent comparison. Add estimated top-up subtotals only where automatic purchasing is intended and a reusable payment method will exist. This worksheet gives the billing owner a practical threshold for revisiting the plan. It should be updated after actual usage is available, rather than treated as a promise that every shopper will consume exactly the same amount.

Map a customer promise to its required capability#

Write one sentence for each experience your website promises. "Explain our return policy" depends on accurate enabled Knowledge. "Show the customer's private order status" needs an eligible read Action, its provider connection and customer ownership checks. "Submit the agreed delivery-address change" adds a supported write, current test and explicit confirmation. Those promises require different operational preparations even if their support volume is identical. Use the exact journey to choose capacity and features. An attractive demonstration is not evidence that the production provider will accept the same request for your customers.

Then describe the fallback when an operation is unavailable. Keep a current contact route and explain which tasks staff handle directly. A higher plan can make a capability eligible; it cannot grant permission to another company's records, create a missing endpoint or determine your refund policy. Before publishing the promise, run a success case and a deliberately unavailable case with safe records. If the required provider integration is not ready, launch the public-answering experience first and describe that scope accurately. This avoids selling an automated outcome that the subscription alone cannot deliver.

Record the decision for the people operating it#

A useful plan handover names the selected workspace, required sites, billing interval, expected units and the workflows that justified the choice. Assign a person to review invoices and automatic purchases, someone to maintain Knowledge, and an owner for each connected operation. These can be the same person in a small business, but the responsibilities should still be explicit. Include the date when the active monthly allowance ends and how long full conversations remain readable. A staff member investigating an issue needs those operational dates, not just the marketing-page plan name.

Keep the agreement between the commercial choice and actual setup visible. For example, document that Business was chosen for order-status reads, but address changes remain a staff task. If the business later asks for automatic changes, revisit the required write capability and provider controls before modifying the website copy. When someone leaves or a provider endpoint changes, use the handover to locate the affected owner and tests. Review the plan after a normal usage period using actual counters, purchase history and support needs. Keep the decision record free of installation tokens, card details and private customer messages.

Compare a concrete business workload#

Suppose your shop needs 800 units in a busy month, only public delivery answers, and a seven-day review cycle. Core plus three paid 100-unit top-ups adds a $30 USD subtotal before applicable tax to its subscription cost. This is a planning example, not a promise that exactly 800 unique shoppers consume 800 units: long answer groups, new six-hour windows and browser identity affect the count. Now suppose the same shop needs private order status. Capacity alone no longer decides the plan, because read Action eligibility matters. Changing the business requirement can change the appropriate plan even if traffic remains identical.

Verify the outcome and keep safe evidence#

After purchase or a change, record the effective plan, billing interval, active usage allowance, usage-period end and subscription renewal date. Check the settings the team actually uses: website count, required Action mode, available transcript maximum and any custom identity. Ask one controlled source-backed question, and test an eligible connected operation if it is part of your customer workflow. A correct invoice does not prove that the endpoint is configured or that every page has a working widget. Keep the commercial check and operational launch check together in your handover notes so the next person can distinguish them.