Support Stack E21: Procedures Are Recipes. Fin Skills Are a Kitchen. with Brian Branca (Fin)

Procedures give Fin a recipe. Skills give it a kitchen. Fin Skills were the quiet hero of Pioneer, and plenty of people are still asking what they actually are, and whether they should migrate everything.

In this episode, Brian Branca (AI Conversation Designer at Fin) joins me for a third time, six days after Pioneer. He walks through a real skill in the beta, and we compare it with the procedure editor: trigger, tools, instructions and guardrails. We also look at turning a monster procedure into a skill using Operator, and which jobs should stay procedures.

If you own Fin procedures, build troubleshooting flows, or you’re an Intercom admin wondering what to do while you wait for beta access, this is a practical look at where Fin Skills fit. Spoiler: your content still comes first.

🔗 Resources mentioned:

Getting started with Fin Skills (Intercom Help): https://www.intercom.com/help/en/articles/16498277-getting-started-with-fin-skills

Support Stack Ep. 16 with Dawn Perrott (14-factor content checklist): https://www.youtube.com/watch?v=fY_Ylah3jcQ

Follow Brian Branca on LinkedIn: https://www.linkedin.com/in/brian-branca/

Want daily, practical tips on getting the most out of Fin and Intercom? Subscribe to my daily email list.

Episode transcript

Conor Pendergrast (00:00)

Hello and welcome to episode twenty one of Support Stack.

So Brian Branca, AI conversational designer from Fin, a familiar face on the Support Stack podcast at this point. You are back for your third appearance. How are you doing today?

Brian (00:24)

I’m doing great. How are you, Conor? I’m so happy to be back again.

Conor Pendergrast (00:28)

I am glad to have you back. And we have you back for a very specific reason actually, which is that we are recording this merely six days after the Fin Pioneer event, which is I would say the marquee event for Fin every year. And I feel like last Wednesday was a bumper event. How did you find it?

Brian (00:50)

I always anticipate watching the cool stuff that they’re gonna unleash to the world. And so this year was no different. It was very exciting. Lots of cool stuff.

Conor Pendergrast (01:00)

Yes. And so we’re gonna talk about just one of those cool things. But I think it’s funny, I think it’s probably gonna be a bit of a quiet hero from the event. Like we look back and think, actually that was one of the product features that got announced. Had some questions around it. So that’s part of what we’re doing here, is demystifying it. But we’re talking about Fin skills. So can you set a little background here for… how much do you know about the genesis of skills and how it came to be? How much can you share about that, the inside secrets?

Brian (01:37)

Yeah, for sure. But I think I love how you framed it as a quiet hero, because I completely agree. It kind of slipped in there, these skills, but once people start using them, they’re gonna see the true power that they hold.

As far as the origins of the skills, so we had procedures, right? They’re basically a step-by-step playbook that you can offer to Fin to solve complex customer issues. And those were working great. We worked with procedures and gave it data connectors to solve customer queries that we weren’t able to solve with knowledge alone. But a lot of the feedback, or some of the feedback we were getting was, hey, how can we make this procedure more agentic and less rigid, right? Because with procedures, you have very distinct steps, right? If you remember, you have conditionals and actions, subprocedures within the conditionals, and it follows kind of the step, sort of like a chef would follow a recipe step by step. And some of the feedback and some of the ideas we had internally were, how can we make this maybe less deterministic and more agentic, I guess, would be how the idea started.

Conor Pendergrast (03:05)

So effectively, how do we make procedures slightly less procedural, you might think?

Brian (03:10)

Yes, exactly.

Conor Pendergrast (03:11)

Yeah. Right. Which is funny and it is interesting because I feel like for those people who used Fin Tasks, going from Fin Tasks to Fin Procedures felt less procedural. It felt more agentic because it definitely felt more like Fin got less stuck and was more able to interpret what the customer said or when the customer did something unexpected and was able to take those steps in a little clearer way. And now we’re seeing, okay, like cool, there’s still a place for those rigid step by step one, two, three, four, five, six, but there’s also a real need for, as you described it, more agentic, less one, two, three, four, five, step by step, more of that creative approach by Fin in a lot of ways.

Brian (04:04)

Exactly right. Yeah. I think in Pioneer, Paul Adams talked about skills, like they’re better for troubleshooting when the end result exactly isn’t clear. When the customer has a non-specific troubleshooting question, skills would be better at handling those types of complex queries.

Conor Pendergrast (04:31)

Yeah. So I got access through one of my clients, I got access to the Fin Skills beta. I think it was the day of, or the day after Pioneer. And I wasn’t totally convinced. And then I happened to have a procedure that I needed to make some changes to, and it was a procedure that was only about a week old. So it was still fresh in my mind. And it was also one where I had this little itch in my head where I was like, I think this is… it was a troubleshooting procedure. And what I realized was there were lots of symptoms of a problem. There were actually lots of explanations of the problem, as in lots of causes of the problem. So the customer could report it in different ways, and the explanation could be different based on their setup, and the solution depended entirely on the actual cause.

And so I got to the point where I was like, my god, I’m gonna have to add… I was looking at a procedure and it already had two subprocedures and it had a bunch of conditions and I was like, okay, well, we’ve updated the data connector’s response so that it has these extra fields and now okay, what’ll I do? Okay, I’ll go into this subprocedure and then I’ll add this condition. And I’m gonna need to point to a different subprocedure now that I’ve created. And so I had that pause of saying, I’m gonna see if a skill can do this. And I told Operator, transform this procedure into a skill, and it did it. And I slimmed it down a little bit because there were a couple of things in there that made sense in a procedure, didn’t make sense in a skill. And I tested it, and because we had… and we’ll get to this, but because we had the content and the data connectors and a little bit of guidance through the skill and a little bit of extra context there, it worked way better, straight off the mark, with a lot less work for me. And that was my moment of like, okay, so there is something really interesting here for skills. It isn’t just procedures for lazy people.

Brian (06:30)

I love that. No, I had the exact same experience with you where I took the same thing. I had like this monster procedure with a million conditionals and a ton of subprocedures, and I’m like, my gosh, I think this would be better as a skill. How can I create a skill from this monster procedure? And I took the same approach. I used Operator. And Operator gave me way more than I actually needed because it went through and it looked at all the conditionals and all the subprocedures and it gave me a ton. So I was able to go through that, slim it down a little, and then get the skill into some good shape and same thing. It’s been working wonderfully for me so far.

Conor Pendergrast (07:17)

Hmm. Yeah, now in my head I do have one mega procedure for one of my clients where I’m like, I wonder if I could do that through a skill. But actually that brings up a good question of, when does it make sense to stick to a procedure then? Like should we all just go and migrate our procedures immediately to skills? What’s your take on that? Or a better question: what are the procedures, or what are the elements of procedures in, let’s say, the Fin workspace, where you look at that and think, I’m not going to change that one. That needs to be a procedure, not a skill.

Brian (07:53)

Yeah. Yeah, that’s a good framing, because you’re right. You’re absolutely right. Just because skills has been released, it doesn’t mean that, let’s take every procedure that we have and let’s turn them into skills. There may be a day when that happens, but I would say that day isn’t now. There still are good use cases for procedures, and I think the best framing that I’ve found is, I was trying to explain to my teammates the differences of procedures and skills and when you might use one rather than another. And I kind of landed on an analogy like, if Fin was a kitchen or a chef, right? Where a procedure follows a very rigid step by step, whereas a skill is more you give the ingredients or the tools to Fin, and you let Fin cook its own recipe, essentially.

And so if we’re mapping that onto actual examples, one example that comes to mind in our production workspace is related to email bounce list, right? So a customer will write in and say something like, hey, you know, why is this user on the email bounce list? A procedure is very good at this step by step. It’s like, customer said that user is on the email bounce list. Let’s look up that user. We can use a data connector here. We’ll check to see if the user is on the bounce list. If they are, let’s remove them. If they’re not, let’s tell them that the user isn’t on the bounce list. And if they are on the bounce list, we can remove them and send a message back to the customer saying that the end user was removed. And so it’s very step-by-step, very related to conditions, like if this then that, if that, then this, so on and so forth.

And then on the other side, for a skill, I found a lot of success with a skill that we’ve implemented for series troubleshooting, where if you can imagine a series, it could be many different things, right? It could be the series itself or it could be the product tour or the chat message or the wait block or whatever within the series. And so there’s many different things that could be the issue, but if we set it up with a skill, the customer can provide the URL of the series, and then we can prioritize content within the skill. And Fin has sort of all it needs to cook up its own thing and provide a response or resolution for the customer. And so on one hand, the procedure, you can think of it as more step by step, more deterministic. And then on the other side, a skill would be more agentic and less deterministic, sort of providing tools to Fin, and letting Fin solve the issue by taking many different roads possibly to the destination, so to speak.

Conor Pendergrast (11:11)

Super. Okay. And I think this is worth calling out, because we said this the last time when you were on. So you were on episode nineteen as well. And one of the major points that came up, and the thing that we’ll continue to reiterate, is in particular with Fin’s skills, the content that you have available to Fin, if that’s not well written and if that doesn’t actually… in a way that Fin understands it. That doesn’t actually address the problems that customers are going to be facing, your skills are not going to perform as well. So to go to a specific example, you said that you used prioritise content in a skill. Well, you have to have the content to prioritise it. So that is the most important part.

Brian (11:57)

I think that’s great that you highlight that. And I think this is an opportunity to plug my teammate’s episode with you, Dawn’s episode, where she appeared and talked about her role as the knowledge manager at Fin. It really is the most important part of building that foundation of not only building a good help centre, but optimising it and creating a strategy for continually improving it as well. You know, yeah.

Conor Pendergrast (12:27)

Yes. So go back to episode sixteen for that with Dawn Perrott. She and I… honestly, I reference that episode and that fourteen-factor checklist, I reference that probably three to four times a week because it is the key part of Fin’s performance, is the content that underlies it. Okay, so as you know from being a past guest, you know I like to show people specifics and show people, especially for something like skills, because it’s so new and it’s still in beta as of recording. I think it’s probably a good idea to show people what it looks like so that they can get an understanding of the structural differences between a procedure and a skill for those people who are aware. So you’re showing us a skill now. This is what a Fin skill looks like at the moment. We’ll say at the moment, because it is in beta, so things are liable to change.

Brian (13:21)

Yeah, right. Yeah, that’s a good point. So it looks very similar to the procedure editing screen, but you’ll notice that there’s just sort of like this big block of text, right? And it’s sort of what we call the playbook, right? What you want Fin to follow. And so you can see up here we have the same trigger, like when the skill should trigger. It’s the same as when we had procedures too, like you’re explaining when this specific skill should be triggering. But this is the part here that’s a bit different than what you would see in the procedure, right? So we have the tools. And so before I mentioned Fin being like a chef in a kitchen, these are like the ingredients that you’re giving Fin. We have the data connectors, and then also any content that you want to prioritise for Fin to look at or access when the skill has triggered.

Conor Pendergrast (14:22)

Mm-hmm. Yeah. Interesting. So, and to call it out, if you want to be able to reference specific data connectors down below in the instructions, add them as a tool first. Yes, ‘cause you won’t be able to find them otherwise, right. Yeah. And I will say that makes it a lot easier to manage in the instructions, because for my main client at the moment, they have a hundred or so live data connectors. And so every time I wanted to reference one within a procedure, it was like, okay, long list, long list, long list, wait for it to come. Okay, there you go, every single time.

Brian (14:58)

Okay, cool. Yeah. And so I actually created this skill directly from Operator, and you can see it’s…

Conor Pendergrast (15:05)

Super. Thank you, Operator.

Brian (15:06)

Yeah, thank you, Operator. And you can see it’s organised by instructions, and then there’s a top heading for purpose, and then it’s explaining to Fin what information you’re gonna need to gather from the end user, and then providing some guidelines like confirming before you actually take an action with the data connector and applying the change. And then at the bottom, guardrails. These are things that you want to make sure that Fin or the skill always does in the conversations. So you can see, like if I go and sort of toggle my screen, you can see how the setup is different, where this is the old procedure, or the procedures, and they’re step by step and they’re conditions with the if else and else, and then here with the skill it’s just sort of a set of instructions or a playbook that you give it along with the tools to sort of do its thing.

Conor Pendergrast (16:09)

Yeah, yeah. It is a very different way of doing it. Now, so what’s interesting is you haven’t explicitly… so you called the policy, the content up above in the list of tools that you have, but you didn’t reference it down below, presumably because Fin’s just like, okay, well I’ve been told I’m inside the skill, I’m prioritising the fair change policy, so I don’t need to be explicitly told down in the instructions that I should look at that. I’ve already been told that I need to look at that. Is that a fair assumption?

Brian (16:44)

Yeah, that’s a great call out. That’s exactly how it works.

Conor Pendergrast (16:46)

Yeah. Okay, cool. So I’m curious. Obviously this is not a real Fin skill. How have you found it working so far in how you’ve been testing it? Both from a customer experience perspective, which I care about, but also from an AI conversation designer experience? What’s been different? What’s been better? What’s been more of a challenge?

Brian (17:14)

Right. So I think what I explained earlier is definitely true, where there are definitely use cases where you would stick with the procedure, and I outlined an example of that, where there’s a very clear happy path, and then maybe there’s a very clear fallback too. You would use a procedure, and I used an example like the email bounce list example, or let’s say you’re an e-commerce site and you’re selling products and you have a procedure for when a customer wants to return an item, right? So that, in my mind, would go to procedure there, where it’s a very clear thing what the customer wants to do. And they would follow this path if they were gonna return, and if there’s an issue, that would hit this path. And so we’ve seen in our production workspace that that is true.

But on the other side, with the skills, when the happy path is not as clear or there are many different roads that get to a resolution, the skill is just very good at troubleshooting something that isn’t clear at the outset. And I think you brought this up earlier, where we can’t always expect our customers to explain their issues super clearly at the outset of a conversation, right? We can’t expect the input to be perfect every time because it just isn’t. And so the skill is very good at being very conversational back and forth and getting to the root cause of the issue, determining the root cause, and then finding a way, based on the tools that it has access to and the content that has been prioritised, to find a path to a resolution.

And so what I have noticed, and we’ve been sharing these examples with our manager, the head of AI support and the VP of customer support at Intercom, or Fin, excuse me, these amazing examples of how it’s able to start with something that is not very clear, where even a human might have trouble understanding what the customer is asking, and then it just keeps going with the tools that it has at its disposal to get to a resolution in a very conversational, natural way. So I’ve been absolutely amazed by that.

Conor Pendergrast (19:34)

Yeah. So I have to say I was very impressed. I was sort of taking existing simulations and rerunning them under a skill after I had made that move, taken the procedure and moved it into a skill. And the conversations were a lot shorter as a result from Fin’s side. And it was interesting. It was definitely a much better experience. There were some interesting things as well. So I saw somewhere that Fin can run multiple skills at the same time as well if it needs to. So it’s less of that, not getting stuck, but like being in a procedure and then it takes quite a lot of the time to get it out of the procedure. And I will say it seems like it’s got stuck. Whereas if it’s running multiple procedures, or excuse me, multiple skills at the same time, it has the potential to… well, it’s more likely to be able to solve the problem as well. If you have something like, I don’t know, a product that has lots of overlapping terminology, or lots of overlapping, again, going back to what I was saying earlier, a problem could have multiple causes. Maybe you have different skills for those. And then Fin just works out what the best skill is on the fly and less, as you were saying, less deterministically and more agentically.

It is funny, Fin’s skills remind me a lot of a skill in something like Claude, and a lot less like, I don’t know, a workflow in Zapier, you know? A Zapier workflow has very defined conditions. And it starts from the top and it ends at the bottom. And you have to go down those pathways. Or at least the traditional zaps did anyway. Whereas with Claude, it can kind of jump around quite a bit and get creative. And there’s a downside to that. There are times where you definitely want a zap and you definitely don’t want Claude’s creativity. But they solve different purposes and they solve different problems.

Brian (21:39)

Yeah, I think that’s a great point, where now we have the full spectrum of deterministic to non-deterministic. We could start with just the old school workflows and maybe that’s the best use case for what you’re trying to solve. Something less deterministic, you get to procedures, and then something which is very agentic. Now we have the skills, which is a great addition, I think, to the family.

Conor Pendergrast (22:05)

Yeah. I mean, I would say even more deterministic or agentic than that is just pure data connectors and content. There’s no strict instructions for Fin. Fin is just going based on using standalone data connectors and using your content.

Okay. So let’s say someone doesn’t have access to this Fin Skills beta yet. Are they just stuck? Can they do nothing to prepare themselves for getting access to Fin skills in the future? What would your one suggestion be for how they could best prepare for when they eventually get Fin skills access?

Brian (22:40)

Yeah, cool. That’s a great question. I think, and you talked about this at the beginning, but we’re thinking once you have access to these skills, like how can we get everything over to a procedure right away? But you don’t need to think like that. I think if you use the analogies that we talked about throughout this conversation, I would start just in your mind organising the procedures that you have, the problems that you’re trying to solve, and try to put them into two buckets. What are problems like cancelling a subscription or returning a product? What are problems like that that should stay procedures? What are the ones that are more troubleshooting related, where there maybe isn’t a single correct answer or a single destination that you’re trying to get to? And trying to think about your procedures like that, which ones are good candidates for this more agentic style. I think that would be the best way to start preparing yourself for once you have the skills, what’s a good use case for them? And not just building a bunch of skills just because you have access to them, but using them deliberately for the best possible use case, I would say.

Conor Pendergrast (23:56)

Super, super. And then while you’re doing that, make sure that your content that Fin will use is up to date, is accurate and is complete. Covers all of those scenarios.

Brian (24:08)

Yeah. I would say that’s the most important thing. You need to have that covered first. And then you can worry about these agentic actions.

Conor Pendergrast (24:18)

Yes. Super. Brian, well, this was absolutely fascinating. Like I said, we said this in the pre-show, but Fin skills really feeds into my laziness. Because the instructions here are so much easier to write than in a procedure. And genuinely it’s just taking it from being a whole bunch of awful conditions and having to think in a really strange way and try and be predictive, whereas Fin’s skills are a lot simpler. So I’m very grateful for them. Thank you for feeding my laziness.

Brian (24:52)

Yeah, and I’ll just remind you though, that if you have a mammoth procedure, like a lot of us do, you can always use Operator to transition over to the skill. And it’s not gonna give you the perfect skill, but it’s gonna give you a starting point and something that you can iterate on. Yeah, I just wanted to say that.

Conor Pendergrast (25:11)

You’re absolutely right. Yeah. And I will maybe send you a screenshot of the sidebar with all the subprocedures for that one. It’s intimidating. But actually, just to talk about it as well, I know I was trying to wrap up, but you can reference a skill from a procedure. And so what I could start doing is break that procedure down into skills, and then I can deterministically get the right skill, because maybe I want to start that way, and then eventually I just evolve that big long… and it is fully troubleshooting, evolve it all out so that it’s all in skills. So I don’t have to do it in one fell swoop either. So anyway.

Brian (25:55)

No, you don’t. And I’d love to hear about, if you do that, what your results are and what your observations are, ‘cause that’s very fascinating.

Conor Pendergrast (26:01)

Yes. I’ll get permission from the client to document the whole horrifying process. Right, Brian. So where can people find you online and how can we be most useful to you?

Brian (26:12)

Yeah, I think the only place you can find me is LinkedIn. Brian Branca on LinkedIn. And I love interacting with folks. I’m posting all the time and talking with people about Fin and procedures and skills in the comments. So I’d love to talk to you there.

Conor Pendergrast (26:27)

Super lovely. Well, if you are curious about who I am, how did you get here? I’m Conor Pendergrast. You can join my daily email list if you want to hear all about Fin five days a week, if you are also a Fin obsessive. Again, I’ll say the AI agent, not necessarily the company. That’s customersuccess.cx/daily. Please like and subscribe and feed my ravenous and undying ego. You can do that using a button somewhere around here to subscribe to this YouTube channel. Please do like it. I get very sad when no one likes my videos. And I will see you at a future episode of Support Stack. Thank you and goodbye.