Support Stack E18: Operator Won’t One-Shot Your Fin Procedure with Brian Branca (Fin)
Procedures are the answer to complexity, not a fix for a knowledge base that isn’t ready. Brian Branca is an AI Conversation Designer at Fin, and he spends his days designing procedures and iterating on them. The first thing he’ll tell you is that plenty of the topics people reach for a procedure to solve should have been handled by a well-written help article instead.
In this episode Brian walks through how he decides which topics deserve a procedure — conditionals, branching on a customer attribute, a data connector doing real work — and the drafting process that gets one live safely: adding himself as the test audience so a half-built procedure never reaches a real customer, running procedure simulations to see how Fin handles a multi-turn conversation, and getting a teammate to sanity-check the logic before he clicks set live. We also get into Operator now it’s generally available: where it genuinely saves you an afternoon, and why a one-shot prompt won’t hand you a finished procedure.
If you own Fin content, run a help centre, or you’re an Intercom admin weighing up your first procedure, this is a practical look at when a procedure is the right tool, what to watch in the first hour after it goes live, and why an honest change log will save you a week later. This is Part 1 of three with Brian.
🔗 Resources mentioned:
How to build a Fin procedure that improves over time (Brian’s article)
Ep. 09 with Tobi Davis — how they hit 75% resolution on content alone
Ep. 16 with Dawn Perrott — the 14 factors, walked through one by one
Ep. 15 with Dawn Perrott — Operator’s memory holds your whole knowledge base
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 eighteen of Support Stack. So, Brian Branca from Fin, AI Conversation Designer, how are you doing today?
Brian (00:17)
I’m doing great, Conor. It’s great to be with you.
Conor Pendergrast (00:20)
Well, you are the second guest from Fin that I’ve had on my esteemed podcast. Obviously your colleague Dawn was here a couple of weeks ago and I really enjoyed my chat with her. And after that I started thinking, like, that was mostly on the knowledge side. I wonder what are the other ways that people use Operator, but also just what are people doing inside Fin to make Fin work magically on a context and on a data and on a data connector and on an actions basis. And your name came up because you have the best, I think, title for our current era of customer support, which is an AI Conversation Designer. So what we’re talking about today is, like, procedures, but also I’d really like to dig in: what on earth is an AI Conversation Designer?
Brian (01:11)
Yeah, it’s a fun one to explain to my mom. It’s such a new job title, you know.
Conor Pendergrast (01:18)
Yeah.
Brian (01:18)
But yeah, an AI Conversation Designer is, in my case, I’m working with Fin all day and I’m trying to optimize how Fin interacts with our end users, our customers. And so that involves configuring the tone that Fin uses through guidance. And then most of my job the last couple of months has been really working with procedures. And so procedures allow Fin to respond to complex customer queries. And so what I’ve been doing is designing the procedures and iterating on them to improve the customer experience and resolution rates. And so one of the things that I found out very quickly is, you know, you could follow a help center article to create a procedure — that’s relatively straightforward — but it’s really the iteration part that is the most difficult. You have to really keep an eye on it and it’s not just a plug and play type of thing. You really have to keep an eye on it and make sure it’s performing and there aren’t any regressions, and when you see a dip in a specific metric, you kind of know what lever to pull. And so most of my day to day is related to reviewing Fin interactions and then iterating and trying to improve Fin’s performance.
Conor Pendergrast (02:35)
Excellent. Okay. So for viewers, we’re actually going to do — I’m very pleased we’ve got three episodes with Brian, and so I would suggest pressing the subscribe button, because the three things we’re going to do is: today we’re talking about how, when and why to use procedures. The next episode is going to be “my procedures are live” — exactly what Brian was talking about. Now what? These are live and what do I do next? And then the third one is, okay, well how do you handle those bigger overhauls and structural changes for procedures. So that’s our three things. So I guess, Brian, that starts with the natural first step, which is like, okay, well, you just talked about what a procedure is. So a procedure is just a set of instructions for Fin to handle complex conversations, right? So when’s a good time for Fin to be instructed to use a procedure?
Brian (03:29)
Yeah, so in our case, we really try to analyze what our customers are writing in about. And so we track all of the topics and we have a pretty good idea of the incoming questions. And then we take that information and we try to determine which topics would be best handled with a procedure. And so when you have an excellent knowledge base like we do — you know, Dawn touched on that in her previous episodes — when it’s mostly informational type queries, if you have a great knowledge base like we do, usually a procedure isn’t necessary. So a procedure would be something more complex, where you have to add in some conditionals or you have to take some action with a data connector. And so once we’ve kind of scoped it out that way, we start the process of designing a procedure and drafting the procedure.
Conor Pendergrast (04:31)
Okay, super. So here’s a question then. You mentioned if you have a great, well crafted, well structured for an LLM like Fin knowledge base, you will need procedures less. If you’ve got, like, a sort of half baked, not well updated knowledge base, is that a good time to use a procedure then?
Brian (04:53)
That’s a great question. And I guess I’ve never really thought about it from that side of things. I would say you would use a procedure when you have some complex flow, whether there has to be specific conditionals based on the customer who’s writing in. Maybe it’s a data attribute where you want to branch — where if the customer has this attribute, we go down this path, we take this action, or we route it to a specific team this way. If they have another attribute, we route them to another team, or we apply a tag or something of that nature. So I guess it all would come down to how complex — like, what problem are you trying to solve, I guess is where you’d start from. And so if you don’t have an up to date or well thought out knowledge base, I guess I would start there. I guess that’s where you should put your effort to start with. Like, go and watch what Dawn talked about related to knowledge. This reminds me of a conversation that I had with a customer last week, where our AI support team was talking to a customer who has, like, this really, really high resolution rate. And we’re talking to him, and we get to, like, the end of the conversation, he’s like, and by the way, we haven’t added any procedures yet. And all of us were like…
Conor Pendergrast (06:18)
Ha ha.
Brian (06:19)
Right? And so that means that they have spent so much time making sure they’ve optimized their knowledge base and they’ve kept it up to date. And they have structures in place to make sure their knowledge is constructed in a way where Fin can resolve conversations. So I think that illustrates how important your knowledge really is at a fundamental level, making sure that’s in place first. And then he said soon they’re going to be adding in procedures where they’ll be using data connectors and things like that. So that sort of answers the question — where when you’re doing more complex tasks, when you have to get information from an external platform or update information in an external platform, or branch using the conditionals as I mentioned before.
Conor Pendergrast (07:06)
Yeah. So yeah, I strongly agree. It’s funny, I was just recording and editing — I have my Support Stack Solo, which is just me talking to myself. And I was just doing an episode of that, and that was exactly about that, like the switch from informational to personalized to action driven conversations handling, and like those three being sort of stages along the AI support journey with Fin. And I think if you haven’t absolutely nailed your knowledge center and your help content and all of your organizational processes that will keep that fresh forever, then don’t start adding the complexity of the next stages yet. And it reminds me of past guest Tobi Davis. So you can watch where he was talking about — they got to, I think it was, seventy five percent. They got to a seventy five percent resolution rate, and this was, I think, a year ago, a seventy five percent resolution rate and didn’t have a single procedure, no data connectors, nothing more complicated than great content and some guidance in there and some attributes in there which Fin could interpret through guidance. So I strongly agree. But with the caveat that it definitely depends on the kind of business, the kind of product, the kind of customers you have as well. Cause one of my clients is definitely nowhere near — was nowhere near that on content only. And the complexity of the customer conversations meant that Fin had to have a huge amount of context in order to be able to confidently personalize the response and answer the customer in front of it. And with just generic information based on content sources was not enough for that. Okay, so cool. So those are the situations where you should use a procedure and where you shouldn’t use a procedure. Like, what are you thinking about when you’re designing a procedure? Like, do you just sort of make it up as you go along, or do you have a particular thought partner for procedures? What do you do for this?
Brian (09:12)
Yeah, I think it’s sort of like drafting — like, back to my university days. It’s almost like drafting an essay or something, where there are drafts, there are layers involved, where you kind of scope out what problem you wanted to solve, and then you build out your first draft of it. You continually test along the way. Like, for example, throughout the process of drafting a procedure, I add myself as sort of the test audience, so I can test it out so it doesn’t trigger for a wider audience.
Conor Pendergrast (09:49)
So I’m not suddenly interacting with your brand new procedure.
Brian (09:52)
Yeah, exactly right. Yeah. And so, like, test, test, test, test, test — and then iterate that way. So, like, even before setting it live, I’m iterating. So I’m drafting, I’m adding conditionals. I’m tweaking the language in the conditional. I’m using procedure simulations to see how Fin is going to be answering in a multi-turn conversation. And then, once I’ve sort of — I feel comfortable with the state that it’s in and I’ve had, you know, a teammate look at it, I’ve tested it, I’ve used simulations, and I’m feeling pretty good — then the moment comes where you click the “set live” button. But I think it’s really important to understand that that clearly is not the end. I mean, once you set it live, you’re, like, watching it like a hawk, right? You’re looking to see how it’s performing, you’re looking at the metrics, you’re looking to see if there are data connectors, if, you know, if everything is returning successfully, things of that nature. And then, you know, the real work of the iteration on the procedure begins.
Conor Pendergrast (10:58)
Absolutely. So, thinking about that creation, or the — like, before you’re clicking the big scary “set it live”, “save changes live” button. I think the genesis for why I was really interested in talking to you was because Operator has just — as of recording, it just came to general availability about a week ago. So I’m curious, like, is there anything that you could help — any way that we could help people who are staring at a blank canvas of a procedure to take that first step and to take that first leap. Like, what’s a good approach to take if we’re thinking about it with Operator as your sidekick, or as your tool in your tool belt?
Brian (11:44)
Yeah, I think you approach it the same way you would before Operator, and then Operator now just becomes your partner. So, of course, this doesn’t prevent you from, like, doing all of the prep work that you have done before. Now it’s just…
Conor Pendergrast (12:01)
Yeah.
Brian (12:01)
…you still do that work, but then you add Operator to the mix and it becomes like your partner, and you have a conversation with it and get it to a specific point where you feel comfortable with Operator either drafting the procedure, or — I’ve even experimented with Operator drafting the procedure, I’ve experimented with having a conversation with Operator and then building it manually myself based on what Operator says. So there really are many different paths you can take. But, like, I was on the support team before I moved into the role of AI support — the human support side of things. And it was always so important with a complex product like we have to kind of always, you know, be talking to your teammates about specific ideas or thoughts, or, like, just kind of getting a sanity check. And it’s like Operator now is almost like your sanity check. You can treat it like a teammate and talk to it like a teammate, and then even go as far as drafting your procedure through it. But also, again, it’s like if you’re using Operator to create a procedure, you’re still gonna want to go into the procedure itself and manually walk through it to make sure everything is set up the way that you want it to be. It’s just, it makes the process much easier because it’s like a teammate that you can work with.
Conor Pendergrast (13:30)
Yeah. So, what I remember — I think it was a week ago, two weeks ago — I was sitting there, I had a big fresh new procedure and I’d worked it out and I’d worked out that there were gonna be, like, eight different conditionals that led to eight different procedures, and I was like, man, I don’t wanna set that up. So I just said to Operator, like, hey, here’s what my eight — I need you to add conditionals to this. And then I need you to, like, create new sub procedures and then I need to point to those sub procedures. Cause I’m so lazy. Like, don’t tell my clients, but I’m so lazy that I just didn’t want to do it. And Operator did it in like two minutes. And it meant that I was doing, like, smarter stuff, like testing that the jobs all made sense, cause I had approached it in the job sense…
Brian (14:17)
Mm-hmm.
Conor Pendergrast (14:18)
…and had taken that approach. And that was just really helpful. So I had used Operator for that, like, zero to one, that getting out of the blank page, but I also had used it in those early stages of the procedure before it’s gone live, to make those changes as well over time. I think now — I don’t know if you find this — but I think it’s not a realistic expectation to do, like, what do they call it? There’s, like, one shot prompts, the idea where it’s like you say the magic words and then the machine does the work and then you have a perfect procedure. That’s…
Brian (14:57)
Mm-hmm.
Conor Pendergrast (14:58)
…not what we’re talking about. Like, Operator should not be used for that, because Operator’s got access to a lot of information, right? But it doesn’t have access to, like, your brain, and it doesn’t have access to the whole company context, and it doesn’t have access to your code base. So it understands a lot about your customers and about your product, but it’s only what’s documented on your help site — which, as we just talked about, most people probably not the same as Fin, the company, and so don’t have such perfect help knowledge centers. But, like, I don’t know if you found that, but sometimes it can sometimes feel like people expect to just be able to put magic words in and then you’ve got the finished product out.
Brian (15:40)
Yeah, I think you brought up a really good point about getting yourself from — it’s a way to get yourself from zero to one. At the end of the day, Conor is the expert in the product. And that not only involves, like, the help center docs, but also just the nuance of working with the product, the nuance of working with customers, so being on customer calls, and you’re able to bring your expertise. So you are at the end the judge. But, like you said, going from zero to one allows you to get to a place where you are spending your time on the fun creative stuff, right? So, you know, Operator’s gonna get you a first draft of the procedure and it’s probably not going to be perfect, because you really understand the ins and outs and nuances of what your customers expect and want. And so then you can take what Operator has given you and really use that experience to build out a procedure which reflects the kind of support you want to provide to your customer. And so, absolutely, I’ve talked to customers where I think the expectation is you plug this thing in, you turn it on, and then you walk away and it does its thing. And I think to a certain extent, maybe that’s true with very, very basic informational type things. But for the most part, even with knowledge — I mean, as you know, our Fin product is like, we’re shipping stuff every week. And so the knowledge, it always has to be updated. But when it comes to complex queries and questions that these customers are asking, it’s a constant process of iteration, where Operator can get you from zero to one, and then Operator can even help you iterate after the fact, and you can kind of go through the same process with Operator. I think one of the coolest things about working at Fin — and I’ve been on the human support side, I’m now on the AI support side — is it’s always been framed that it’s AI and human working together, where humans are still the experts and the specialists, but we use this amazing Fin tool to make our jobs easier, so that we can focus on the creative, fun stuff that really matters for the customer.
Conor Pendergrast (18:10)
Yeah. Yes, I totally agree. I think that’s a really great approach. So, I think one thing that could be helpful as well is — Brian, you actually wrote an article that is specifically…
Brian (18:20)
Yeah.
Conor Pendergrast (18:21)
…can you pull that up and just give people a look at the title of that? And I think that this is a really good starting point for people. So if you are thinking through how to create your first procedure, this article should guide you on that. And the procedure — even though it was far from my first procedure — but when I was starting that new one a couple of weeks ago, it was this help article that I was referencing, that I was thinking through and that I was looking at. And so this is Brian’s, and it was published in June 2026, and it’s called “How to Build a Fin Procedure That Improves Over Time”. So I’ll link it in the show notes. But if you’re looking for an approach that is very functional, then it’s a really great article.
Brian (19:04)
Yeah, so this is the article here. And it kind of — this article sort of came to be organically, where I was spending a good part of my week and my days not necessarily building procedures — no, of course that’s part of my job — but, like, the real work: I wanted to frame it in a way where the real work kind of begins once you have the procedure set live. And you need to keep an eye on it like a hawk. I think when I started in my position, one of my teammates said, once you set a procedure live you have to watch it like it’s your baby. And so it kind of came to be from this process. And I looked at our help center and I realized it would be really useful to not only, you know, explain how to set procedures up, but also what to do after they’re set live. And so that’s sort of where I’ve taken this article. And it walks through — I think what is it — six different principles for iterating and improving procedures over time.
Conor Pendergrast (20:09)
Yeah. Yeah. Cool. Okay. So I mean, I think, is there anything else you’d like to share in that initial stage — in that, like, what’s the first, someone getting started with procedures, someone doing their first procedure, or who hasn’t done one in a couple of weeks and wants to do it right and do it with Operator? Like, is there anything else, or have you hit the main points, Brian?
Brian (20:32)
Yeah, I think one of the principles from this article that I learned the hard way was keeping an honest change log, right? And so…
Conor Pendergrast (20:39)
Sure.
Brian (20:40)
…I was making changes to procedures and I wasn’t being very descriptive in my changes. And then when something broke, or we saw, like, a major dip, it became much harder to kind of backtrack and trying to maybe pinpoint where something went wrong or what change caused a change in metrics. And so I would say, I know, like, putting together a procedure can be daunting. It can take a lot of work. And, like, the last thing you want to do is write out 300 characters on what you…
Conor Pendergrast (21:10)
Yeah.
Brian (21:10)
…did to change it. But I really recommend doing that, taking the time to do it, because you’ll thank yourself in a week when you have to go back and be like, hey, what did I do that broke this thing, you know?
Conor Pendergrast (21:22)
Absolutely. Yep.
Brian (21:23)
Yeah.
Conor Pendergrast (21:23)
Yep. I strongly agree with that as well. And…
Brian (21:25)
Mm-hmm.
Conor Pendergrast (21:26)
…it’s not just, like, “updated conditions”. It’s being more specific than that.
Brian (21:31)
Yeah.
Conor Pendergrast (21:31)
Cool. All right, Brian. Well, thank you. So that’s it for this episode. So we’ll be back. The next episode that we’re doing is about the next stage. So it’s about “my procedure is live, now what”, and how we move beyond vibes in knowing that the procedure is working well. You can subscribe to this video, like and subscribe, and you’ll get the next video. You can also sign up to my weekdaily email list, which is all about Fin, the AI agent. Not necessarily about the company, but sometimes about the company as well. I’m obsessed with the AI agent rather than the people who work at the company, I have to admit. And that’s at customersuccess.cx/daily. Brian, if someone wanted to find out more about you online, where would they find you, and how could people be most useful to you?
Brian (22:21)
Yeah, they can reach out to me on LinkedIn. I’m Brian Branca on LinkedIn. I do have people reaching out via direct messages asking me about my role and my approaches and stuff like that. So feel free to drop me a message. I leave posts about articles and things and you can interact with me that way. Yeah, LinkedIn is the best way.
Conor Pendergrast (22:39)
Excellent. Cool. Well, thank you very much and we will see you again soon. Bye.