A support ticket rarely contains everything needed to resolve it. A billing complaint may mean checking the payment, the account state, recent product activity, and whether the customer is even looking at current information. An account that looks inactive may be running plenty of work through browser actions or connected tools rather than chat.

The slow part is rarely writing the response. It is finding and reconciling the information needed to give the right one.

Strawberry is a browser with AI companions built in. A companion works across the tabs and apps your team already uses, so it can bring together the relevant context, work out what happened, and prepare the next action for your review. Depending on the case, that context may include the support thread, account history, billing state, product activity, documentation, previous commitments, and known issues. It pulls in only the sources the question in front of you needs.

That is how we run our own support. Our internal support companion is called Fritz, and the anonymized examples in this guide are based on patterns from its work.

How Strawberry can automate your customer support

Bring Strawberry the customer work already in front of you: the ticket you have been avoiding, the account that looks quiet, the customer who signed yesterday. Your companion picks the smallest useful piece of it and shows you the result before anything is sent or changed.

/getting-started-with-customer-support-and-success-in-strawberry

Bring together the context behind a ticket

Use this when a ticket, an account, or an upcoming call needs more than what the customer wrote today. Strawberry reads the current message, then checks the surrounding records: the earlier thread, account and billing state, recent product activity, prior commitments, and known issues. It prepares a short account of what happened, with each claim linked to its source, and flags where the records disagree.

In one of our own cases, a customer reported that purchased credits had never arrived. The payment and account records were correct; the app was showing an outdated balance. Checking the ticket alone would have led to a refund or a duplicate credit grant. Strawberry separated the customer response from the product issue and prepared both for review.

A customer can be right about what they see even when the records are correct. The reverse happens too: an account that looks quiet in chat may be running substantial work through connected tools. In another case, that wider check turned a churn worry into an onboarding task for a different seat on the same account.

Nothing is sent at this stage. You get the reconstructed story and decide what happens next.

Check whether a quiet account is really quiet

Usage across chat, browser, and integrations, plus the goals and promises on record, so one flat metric does not send the wrong email to the wrong person.

/review-customer-health

Walk into the renewal knowing what was promised

Twenty minutes before a check-in, QBR, or renewal call, you need the few things that could derail it: unmet commitments and who made them, usage that dropped, the open ticket nobody mentioned.

/prepare-for-meetings

Leave the call with a name next to every next step

Notes that split into customer follow-up on one side and internal actions with an owner on the other.

/debrief-a-meeting

Draft the reply from the records

Use this when you are ready to answer, or when a queue needs sorting. Strawberry checks the full thread, the customer's history, current documentation, known issues, and your team's policy before it suggests a reply. For a queue, it applies your own priority and escalation rules rather than a severity score it invented.

It prepares a reply you can send, with the facts it relied on beside it, and a clear next action for cases that are not ready to answer.

In one of our cases, a customer complained about being treated as a free user despite paying. The account they wrote from really was on the free plan; the paid subscription sat on another login. A shallow check would have told the customer they were wrong. Strawberry compared the customer's logins and prepared a reply that pointed them to the right one.

Sending stays with you. The draft is checked against the records, but a person reads it before it goes out.

Triage the queue by what is at stake

Priority, next action, and a first response for each ticket, using your team's rules. Forty overnight tickets become the three to read before standup.

/triage-support-queue

Investigate before you answer

The full thread, the account's history, current docs, known issues, and what your team's policy says, reconciled into a reply you can send.

/investigate-support-case

Prepare a complete handoff when another team needs to help

Use this when a case needs engineering, billing, or another specialist team. Strawberry checks the customer's timeline, what has already been tried, related reports, and the relevant product area. It prepares a handoff the receiving team can act on: impact, timeline, evidence, and the one decision they need to make. Customer-identifying detail stays in support.

In one of our cases, a seemingly isolated launch problem matched a wider pattern among users on the same release. Strawberry prepared the customer timeline, the affected pattern, and the likely product area, so engineering started with evidence rather than a vague ticket. A small ticket can reveal a broader product issue, which is why the check looks beyond the one customer.

Once you approve the route and boundaries, Strawberry can recognize when a case needs another team and prepare the handoff on its own. Filing the issue and updating the customer remain separate, reviewable actions.

Send a human the full case

Impact, timeline, what has been tried, the customer's current message, and the specific decision the receiving team now owns.

/escalate-customer-issue

Create Jira or Linear issues from support tickets

Reproduce the problem, check for duplicates, and file an engineering issue that does not leak private customer context.

/report-bug

Keep it visible until it is resolved

The next update owed, the decision still open, and confirmation that the fix landed, tracked across support and the specialist team.

/close-open-loops

Get a new customer to a first result

Use this when a customer has just signed. Strawberry reads the agreed scope, the sales handoff notes, the stakeholders, and the setup dependencies, and prepares an onboarding path pointed at the outcome the customer named rather than a product tour.

In one pilot, a new RevOps user's first request was half research and half operations: review a set of competitor websites, identify the customers featured on them, and work out how to record those companies in their own systems. Strawberry returned the research and the operational next step together, and the customer's feedback was about as clear as it gets.

Onboarding lands when the customer's own task gets done early. The plan is prepared for your review; the customer conversations stay with your team.

/onboard-a-customer

Turn confirmed resolutions into reusable support knowledge

Use this when a resolution is confirmed or a question keeps recurring. Strawberry checks the resolved case, existing help content, and related feedback. It prepares a help article or an update to one, without duplicating an article that already exists, or a source-linked summary of the pattern for Product.

In one of our cases, a single message contained four unrelated problems: a suspected licensing change, worsening search results, stuck agents, and missing credits. Treating them as one issue would have produced the wrong answer for all four. Strawberry separated them: the subscription was unchanged, the credits had been used, the search issue got a workaround, and the stuck agents became a product signal. The confirmed licensing answer then became support documentation.

One customer message can contain several unrelated problems, and a resolved ticket can become a reusable answer. Publishing goes through your normal review.

Publish the answer once

Turn a confirmed resolution or recurring question into help content the next customer can find, without duplicating an article that already exists.

/create-or-update-a-help-center-article

Show Product the pattern

Group feedback into themes, tensions, and examples with the original tickets still linked. A summary that informs the roadmap rather than pretending to be it.

/synthesize-customer-feedback

Make the method repeatable for your team

Run one ticket from this week's queue through. Correct what it gets wrong: the tone, the routing, a document you retired. After a handful of cases the corrections stop, and what remains is your team's support method, written down. Save it so a new hire handles a billing ticket the way your most experienced person does.

Set up the connected support system

Map the stack, learn from resolved cases, test the focused skills, and add Routines only after the manual flow works.

/set-up-support-like-strawberry

Share the method with the team

Keep a trusted workflow as a team skill so colleagues follow the same checks, boundaries, and handoffs.

/set-up-shared-team-workflow

A Routine repeats the check on a schedule. It never grants permission to send, refund, change an account, file an issue, or publish. Those stay with a person.

Try this starter pack in Strawberry

Getting Started with Customer Support and Success in Strawberry

Help the user see how their companion can support the connected work of helping customers, then complete one useful piece of it. Keep reactive Support work and proactive Success work equally visible without pretending they follow one sequence.

Paint the customer system

Explain briefly that Strawberry can work across the support desk, CRM, account notes, product docs, help center, email, team messages, meetings, project tracker, product, files, and the visible browser. The companion can bring together the context that changes the response, keep sources beside claims, and carry accepted account goals, tone, and review rules into the next interaction.

Show the system through five connected lanes:

  • Understand the customer: bring together goals, history, product context, health signals, prior commitments, and the current question.
  • Respond and resolve: triage requests, research grounded answers, communicate clearly, and keep the next owner and follow-through visible.
  • Coordinate and escalate: package customer impact, route bugs and sensitive cases, and maintain the customer relationship while specialist work continues.
  • Help customers reach value: turn accepted goals into onboarding, progress reviews, useful customer conversations, and clear next actions.
  • Learn and improve: turn verified resolutions into better help content and recurring customer feedback into source-linked product insight.

Support often moves from request to context, response or escalation, resolution, and learning. Success may begin with onboarding, a health review, or a planned conversation. Enter where the customer work needs attention now.

Choose a Support or Success path

Understand the customer or account, current request or goal, decision due, channel, deadline, and available evidence. Use approved context already available before asking the user to repeat it.

For reactive Support work, begin with the current case or queue. Recommend a small, situational set such as:

  • set up a connected support system before scaling repeated work;
  • triage one case or a queue and prepare the right next action;
  • investigate a case the team cannot answer confidently; or
  • carry an approved resolution through verification and reconciliation.

For proactive Customer Success work, begin with the account goal or signal. Recommend a small, situational set such as:

  • review one customer account for progress, risk, and next steps; or
  • turn a confirmed new customer into an owned onboarding plan.

Explain why the options fit. Suggest another connection only when it materially improves the chosen result; do not require the entire customer stack before helping.

Route each job to its owner

  • Set up a support system: read strawberry/customer-support-success/set-up-support-like-strawberry.
  • Triage one support case or a queue: read strawberry/customer-support-success/triage-support-queue.
  • Investigate a support case: read strawberry/customer-support-success/investigate-support-case.
  • Carry out an approved resolution: read strawberry/customer-support-success/resolve-support-case.
  • Package a customer escalation: read strawberry/customer-support-success/escalate-customer-issue.
  • Create or update customer documentation: read strawberry/customer-support-success/create-or-update-a-help-center-article.
  • Onboard a customer: read strawberry/customer-support-success/onboard-a-customer.
  • Review customer health: read strawberry/customer-support-success/review-customer-health.
  • Research, reproduce, and report a product bug: use strawberry/product-engineering/report-bug. Support owns customer impact and communication; Product and Engineering owns product evidence and the issue record.
  • Synthesize recurring feedback for Product: use strawberry/product-engineering/synthesize-customer-feedback.
  • Prepare for or debrief a customer conversation: use strawberry/operations/prepare-for-meetings or strawberry/operations/debrief-a-meeting, bringing the relevant account goals, health, history, and commitments.
  • Coordinate ownership and updates: use strawberry/operations/close-open-loops or strawberry/operations/prepare-a-status-update when that horizontal result is primary.

If no focused skill fits, help normally rather than forcing the work into the closest package.

Learn without leaking customer context

When tone, priority, routing, or health rules are new, calibrate with a representative, varied set before scaling. Start with enough history to see patterns, then widen the set when a case type or pattern is missing. Preserve accepted sources, tone, definitions, ownership, and review rules after they prove durable. Keep customer-specific private context out of broad trend reports and reusable methods.

Share an approved artifact when teammates only need the result. Save a team skill when the group should use the same method. Share the full companion when they need the same ongoing customer context across several workflows. Offer a Routine only after a workflow has a real trigger, named sources, output, destination, approval behavior, and stop conditions.

Keep judgment and actions clear

Use the team's actual priority, SLA, health, ownership, and escalation rules; do not invent a universal severity or churn score. Drafting, sending, refunding, changing an account, granting access, updating a ticket, filing an issue, publishing help content, and making a product commitment are different actions.

Follow Strawberry's active scoped permission for the exact account, destination, and action. Draft or ask when permission is insufficient; stop when identity, scope, impact, or sensitive-data handling changes; verify completed external actions. Suspected security, privacy, data-loss, legal, regulated, or active incident cases go immediately to the team's accepted specialist path.