Why Fin Resolution Stalls (And What Actually Moves It)

Support Stack: Long Read

Fin resolution stalls because most teams only ever feed it one type of input: content. Content alone has a ceiling — often somewhere in the 50s to high 60s. Getting past it means giving Fin two things it’s currently missing: personalisation (who’s asking) and action (the ability to actually do something) — not more content, and not better prompts.

Your resolution rate climbs into the 60s on content alone, and then it just … stops. Good.

Most support leaders read that flat line as a problem. It isn’t. It’s a stage.

I was on a call recently with an edtech company — smart team, already at 66.5% resolution for the year, purely off content. Genuinely solid. But every question that needed context — a user’s permission level, whether their organisation had bought a particular product, a request to delete an account — still went to a human. Not because the question was hard. Because Fin couldn’t see who was asking.

The three ceilings

I think about this as three buckets: content, personalisation, and action. Fin can only clear one ceiling at a time, and almost everyone starts in the same place.

→ Ceiling one: content. Fin reads a help article and gives a good-enough answer — the C-plus, B-minus answer that covers three possible scenarios because it doesn’t know which one applies to you. This is where every team starts, and it’s genuinely useful. It’s also where most teams stay, because it’s the easy part.

→ Ceiling two: personalisation. The questions still landing on your humans usually aren’t hard. They’re simple questions that happen to need context Fin can’t see. “What’s my permission level?” “Does my organisation have this product?” “Can you delete my account?” Easy to answer — if you know who’s asking. Without that, someone admins in, looks it up, replies. Every single time.

→ Ceiling three: action. Letting Fin actually do the thing — delete the account, retry the sync, send the reset link — instead of describing it and handing off. This is where resolution stops being a support metric and starts being an operating model.

This isn’t a Fin problem. It’s a data-plumbing problem. Fin is only ever as good as the data you let it see, and if you’re stuck at content-only, it’s because nothing else has been pushed in yet.

Getting past ceiling two: two ways to feed Fin context

There are two tools for this, and picking the right one matters.

User and company attributes are for information that doesn’t change often — a subscription plan, a company role, a billing status. Push them in daily, or push them the moment they change in your product (better — usually under a minute’s delay instead of up to 24 hours stale). Attributes alone got that team thinking differently about permissions in real time on the call.

But attributes have a limit, and it showed up fast. Their support lead mentioned that customer organisations can create custom roles on top of the predefined ones — “that’s where it gets tricky.” That’s exactly the moment to reach for the second tool.

Data connectors are for information that’s too complex or too frequently-changing for a single attribute — a full permissions JSON blob, a list of the eight different products a customer might have bought, a subscription’s entire change history. Fin calls out, gets a live answer, and can combine two connector calls to construct a genuinely precise response — “you’ve got this permission, but that feature lives in a product you don’t have.”

One thing worth doing alongside either: if your database’s internal name for something doesn’t match what the user sees on screen (a twelve-year-old field name, a UI that’s changed sixteen times since), write Fin some guidance that maps the two. Otherwise you’ve given Fin the data but not the translation.

Getting past ceiling three, before you’ve built the action

You don’t need every action wired up on day one. If Fin can already collect everything — the request, the reason, the account details — but the actual delete or refund isn’t automated yet, use Intercom’s “loop in a teammate” step. Fin runs the whole conversation, a human just clicks the button, and Fin closes the loop and confirms. Your human does the two seconds of work they actually need to do; Fin does everything else.

Two more things worth building in from the start:

→ Narrow it with an audience. Don’t let Fin reach for a data connector on every single conversation — scope it to who actually needs it. Otherwise Fin’s spinning its wheels on requests that will never match.

→ Pass a real user ID, not just a type. If your data connector request only knows “this is a user” rather than exactly which one, you can’t be confident the person asking is the person entitled to the answer. Push a secure user ID over at sign-up or sign-in, and Fin can check “does this specific person have access” before it hands anything over.

The minimum effective dose

You don’t need to solve all three ceilings this quarter. Pick one simple-but-personal request that keeps hitting your humans — a permission check, an account deletion, whatever’s most repetitive. That’s your first candidate. Get Fin the context or the capability it needs for that one thing, and watch what happens to the rest of the queue behind it.

Stop assuming a flat resolution line means Fin has failed. Start asking which ceiling you’re actually up against.

Frequently asked questions

Is a stalled resolution rate always a content problem?

A stalled resolution rate is almost never a content problem — and treating it as one is the most common mistake support leaders make. If resolution has plateaued after an initial climb, the fix is giving Fin the context (personalisation) or the capability (action) it’s currently missing, not writing more articles.

How do I know whether to use an attribute or a data connector?

Whether you need an attribute or a data connector comes down to two questions: does the information change often, and is it simple enough to fit in a single field? Static, simple data (a plan tier, a role) is an attribute. Anything that changes frequently or needs real structure behind it (a full permissions set, a list of purchased products) is a data connector.

Do I need all three ceilings solved before Fin is “done”?

You don’t need all three ceilings solved before Fin is “done,” because Fin is never “done” — it’s maintained, the same way your product is. The goal isn’t to clear every ceiling at once, it’s to know which one is costing you the most right now and fix that.

What if the action isn’t built yet?

If the action isn’t built yet, use a “loop in a teammate” step as a stopgap. Fin handles the whole conversation and collects everything it needs; a human just performs the click. It’s not the end state, but it gets the resolution win now instead of waiting for engineering.