Fin, which we’ve lovingly renamed “Bizy,” is the first agentic touchpoint between Bonusly and its customers. I wrote an open letter to Intercom about Fin last month, and since then we’ve seen Fin’s resolution rate improve by 19% as we continue to tune and integrate it with more MCP tools. 

In that letter, I briefly touched on the fact that Fin has allowed us to re-think the nature of support. I thought I’d expound on that a bit more.

Old support model

Before Fin, we had a support model that is, I think, common across a lot of companies. In our old model, a customer would write in or chat with us about a issue. We had a group of human workers staffed to handle the frontline. We called this group “Tier 1 Support,” and email signatures from members in this group indicated that was the team they were on.

Trickier issues would be escalated by Tier 1 to Tier 2, which was a second group of humans with deeper knowledge of the system and ways to debug it. This group was excellent at helping our customers find workarounds to product limitations, explain esoteric concepts to them, and arming the on-call engineer with context should we need a bug fix. The handoff between our first two tiers was done in Intercom as both groups used that system to manage issues.

Tiers 1 and 2 were staffed on a 24x5 schedule, meaning we’d be responsive to issues 24 hours a day, 5 days a week (US business days).

The on-call engineer, then, composed the third and final stratum in our support structure. Tier 2 met every week to decide the priority of escalated issues they couldn’t fix, and that the on-call engineer should attend to. These were logged in Jira, and the on-call engineer spent the week fixing bugs documented on our TRIAGE Jira board. Jira updates became the conduit through which Tier 2, which still owned customer communication through Intercom, would keep the customer updated with progress.

New support model

Fin specifically, and the breakneck advancement in AI capabilities generally, put us in a position to re-imagine what support could be here at Bonusly. But first we thought it prudent to write down our goals for a re-imagined support experience, then ask ourselves if AI could help us get there.

Goals

1. Resolve most issues really fast, and with 0 to 1 customer handoffs
2. Pull product engineering closer to customer pain

Reorganizing

Importantly, we re-organized the company into a BU (business unit) structure with a weak ownership model for non-support-related reasons. The BUs are:

• Habits: owns most of the “inputs” into our product. This includes our givebox, where people send recognition to each other, and our 1:1 experience.
• Insights: observability layer on top of our inputs. Think “Datadog for human systems.”
• Rewards: reinforces habitual behavior. This is where people convert points they earn into real-world objects.

This structure allowed us to carve up parts of the product and determine which BU was responsible for them.

Mapping features to BUs this way helped us realize we could pull BUs up into the support stack when customers experience pain with the product areas they own.

Cool.

Support was also reorganized under the Engineering team. We decided that it would stay on as a horizontal function; there would be one support experience for our customers who shouldn’t have be privy to the complexity of our org design underneath.

From Support to Support Engineering

The value of specialization is diminishing with AI. Generalists can use AI to do specialized things. We adopted this axiom when creating a new role for our support team. We now call them Support Engineers, and each member has installed Cursor, the Intercom MCP tool (and others), and our local development environment. They have and are learning to use the same tools product engineers use every day. 

The Intercom MCP tool allows them to point Cursor at a customer’s issue, then use it to help diagnose the issue and even prepare a bug fix for it. Our guidance to them is to spend no more than two hours trying to fix a given issue before escalating to the BU.

Expanding the capability of each support engineer means fewer human touchpoints. Our support engineers are able to handle most escalated issues without handing them off to the BU. Continuity like that is a great customer experience.

We’ve also started phasing out “macros”; canned responses that can have the effect of feeling impersonal. Armed with AI, our human support team is now giving customers more, well, human responses.

Fin

Support engineering can’t spend time handling the more complicated issues without Fin’s help. Fin is Intercom’s AI agent. Last month it resolved about 43% of the issues it handled for us. This month it’s resolving 52% and still holds a CX score of 80% (meaning most customers are happy with Fin).

We just got access to Procedures and can’t wait to turn it on for our customers. Procedures will help Fin resolve more complicated issues, and we’ll be rolling it out in stages over the coming weeks.

Fin also gives us 24x7 frontline support, which improves on our old 24x5 model. And what’s interesting is most of our issues come in between 8am and 6pm ET M-F. 

Before Fin, we needed around-the-clock human staffing to handle the long-tail. Now, with Fin becoming more effective resolving customer issues, we can cluster human staffing closer to the hours where most of our volume hits. This creates more opportunity for support engineering to collaborate with the rest of the company (which works US business hours) and ramp into their new engineering-oriented job.

The on-call engineer

Gone is the TRIAGE Jira board. Everyone, including the on-call engineer, works out of Intercom now. The On-call engineer joins support engineering for the week and works the inbox with them. Yes, the on-call engineer actually communicates with customers. 

Our objective here is to put product engineering on the front lines, right where customer pain is. While they do help boost human-support capacity and help our new support engineers manage coding, the main objective is to arm them with a visceral sense of what’s not working for our customers. And if that creates a little more customer empathy than they had before, that’s a win.

BUs

Each business unit (BU) has its own inbox. If support engineering can’t resolve an issue in under 2 hours, they write copious Intercom notes, then delegate the issue to the BU that owns the problem area. The BU gets pinged in their Slack channel:

From here, the BU owns the conversation with the customer. Someone designated by the BU lead hops into the conversation in Intercom, introduces themselves, and explains the situation. Sometimes the customer issue is one the BU won’t fix right now. The BU has to say that to the customer. Gone are the days where teams can postpone a bug fix or leave a workaround in place and let somebody else break the bad news.

Owning customer communication humanizes the work and helps keep our teams grounded.

Have we met our goals?

I don’t know yet. We’ve only been at this for about 2 months. 

I’d like to see more on-call engineers rotate through first. Anecdotally the BUs do like managing customer issues, though. They were hungry for the kind of customer feedback they get now. 

Regarding speed, this graph shows our median time to close issues (including Fin) compared to the prior two-month period.

The darker-blue bar shows median-close time after the new process went live. The lighter-blue bar shows it before. I’ve put a green dot above weeks where our new process was faster, and a red one above weeks where it was slower. With 6 green dots and 3 red ones, it seems we’re faster than before. My Intercom dashboard says about 34 minutes faster, which ain’t nothin’. 

But I think we still have a ton of room to improve on this.

‍

JT

SVP Engineering, Bonusly | LinkedIn

‍