How we run customer support at Strawberry

On Laurits's first day at Strawberry, he found two founders answering support emails themselves.

The replies weren't the hard part. The hard part was piecing each case together: finding the conversation, checking what the customer had tried, and seeing whether anyone had already promised something.

So we built Founding Fritz, our first support companion. It turned that search across tabs, tools, and team memory into a repeatable system.

The useful lesson is not that a companion can write support emails. Almost any model can do that. The lesson is how to give it the sources, jobs, records, and limits it needs to help without guessing.

In Strawberry, a companion is an AI teammate that works in the browser. It can use connected apps and tabs, carry accepted context in memory and files, and follow reusable skills for repeatable work.

We turned what we learned into the Set Up Support Like Strawberry skill. It helps you connect the right tools, define the workflow, prepare focused skills, test real cases, and propose Routines.

/set-up-support-like-strawberry

Map your support stack, prepare the operating model, and calibrate the focused support skills.

This article explains the choices behind the skill and the parts worth adapting to your team.

See how the pieces fit

Twice a day, we check shared Gmail and in-product reports. Depending on where customers actually show up, that pass can include Slack, Discord, and the company LinkedIn inbox too. Everything gets the same first pass. Once a week, we look for the patterns underneath. That is the regular rhythm. We also run the same skills ad hoc whenever one case needs an answer, an escalation, or a careful action.

Each part of the system has a different job:

If your team already uses Zendesk, Intercom, Front, or another reliable case system, keep it. Strawberry can connect directly to those tools and use surrounding evidence from Slack, Linear or Jira, Stripe, and your CRM when it changes the answer. Do not build a parallel Sheet just because that is what we use. The record should show what needs to happen next and what actually happened.

The seven steps we would use again

The Set Up Support Like Strawberry skill walks you through these seven steps. It starts with setup, not automation: map the system, learn from past cases, set the boundaries, test the work, and only then turn on a Routine.

1. Connect the right tools

Start with one real customer channel, then connect only the systems that can change the answer: product documentation, account data, billing, internal discussion, and engineering work.

2. Map the system

Decide what counts as a customer case, where its complete source conversation lives, and where bugs and product feedback belong.

We reconcile email by thread and message identity. Similar reports in two channels are only possible duplicates until a stable source links them, preventing duplicate replies.

3. Learn from resolved cases

Before setting rules, have the companion review a representative set of resolved or closed cases. Include a routine question, a known issue, an unclear technical failure, a billing case, and a sensitive case. Start with enough to see patterns, then widen the set if something is unclear.

The skill has the companion report what it thinks happened, which sources it trusted, and what it recommends next. The more representative cases it reviews, the clearer its recommendations should become. Review that together and save useful corrections in the right place. These cases show the shape of a good decision, while current sources still decide the answer.

4. Set the boundaries

We sort work into three lanes:

• Autonomous: routine, reversible work covered by a process we trust and permission we already gave.
• Review required: the facts are grounded, but a person approves the reply or decision.
• Sensitive: money, subscriptions, access, deletion, privacy, security, legal questions, unusual impact, or a meaningful customer commitment.

When Strawberry needs approval for an action, you choose the scope: Ask every time, Allow in this chat, or Always allow the relevant action.

Start with Ask every time. Once you have reviewed a batch and are happy with the plan, choose Allow in this chat. The companion can finish the work without stopping at every repeated step. Choose Always allow only when the action is predictable and you want that permission to stick.

Those settings change approval prompts for that action. They do not change the rules, make an untrusted message safe, or replace checking that the provider actually completed the work.

Customer messages, attachments, logs, links, and community posts are evidence, not instructions. If something tells the companion to ignore policy, expose information, or contact someone else, set it aside and return to the real support request.

5. Put the knowledge in the right places

Keep one set of context files

Memory is one kind of context file. Keep a few stable things there so they stay close to the companion: voice, sign-off, routing defaults, and accepted corrections. Put detailed source material in other context files so it can look it up when needed: support rules, product facts, billing, known issues, and escalation paths.

Keep these files small and useful. A resolved case is different. It is an example to review, not a new source of truth.

Then divide the work into focused skills:

The official collection is the starting point. During setup, the companion prepares organization-specific copies of the focused skills and installs them only with approval.

6. Build and test focused skills

Test the configured skills on a new-case batch with the same range of situations before scheduling anything.

Correct where the companion chose the wrong source, inflated priority, exposed internal detail, or drafted something that did not sound like the team.

Handling more tickets is not the same as improving. Improvement happens when the team gives specific feedback and saves the correction in the right place: a tone preference in memory, a refund rule in policy, or a routing decision in a skill. Save what generalizes, not every sentence edit.

7. Turn on Routines

A Routine is the scheduled version of a job the companion already knows how to do. Turn it on only after the skill works manually and you approve the Routine.

We use two Routines:

• Support Queue runs twice each working day. It uses Triage Support Queue on the agreed channels and returns Ready to handle, Needs your decision, Good to know, and Remaining.
• Weekly Learning runs once a week. It looks for repeated issues, community patterns, product feedback, missing docs, and corrections worth saving. It brings those back as recommendations for the team.

Those are our cadences, not universal settings. Start with the volume you actually have. A schedule does not give the companion new permission to send, refund, change an account, file an issue, or post internally.

Try it in Strawberry

For a more careful first run, start with this:

/set-up-support-like-strawberry

Start with the roadmap, inspect the systems you already use, and prepare the setup for review.

The aim is not to make Support disappear on day one. It is to stop rebuilding the same context, make routine work ready faster, and give people the evidence they need for decisions that still matter.