What Makes a Great Fin Procedure (And When Not to Use One)
Fin Procedures are powerful.
But they are not the answer to everything.
In this first solo episode of Support Stack, I break down how to decide whether something should become a Fin Procedure at all.
Most teams get excited about automation and immediately start building. The result is often a clever workflow that solves the wrong problem. Instead, I walk through a clearer way to think about it.
You’ll learn when a procedure is the right tool:
When there are multiple logical steps
When there is branching or decision logic
When you need structured information gathered before action
When consistency matters more than creativity
When data from other systems needs interpretation
And just as importantly, when not to use one:
When a knowledge article answers the question perfectly
When Fin’s Guidance can handle it cleanly
When a standalone data connector does the job
When you cannot clearly articulate a step-by-step flow
I also share something that sits at the centre of my approach: there should always be a route to a human. Procedures should increase speed and clarity, not create dead ends or frustration.
To make this practical, I walk through a real example from my own Intercom workspace. I’m designing a lead qualification flow for my website that:
Records structured attributes
Branches based on Fin maturity
Captures team context
Sets availability expectations clearly
Protects my time without damaging the customer experience
This episode is less about configuration and more about judgement. It’s about building the right first procedure, not just building one.
If you’re experimenting with Fin Procedures, trying to improve consistency, or deciding what to automate next, this will sharpen your thinking.
Episode links:
Episode transcript
Conor Pendergrast (00:00)
Hello, I'm Conor Pendergrast and welcome to episode one of support stack solo.
So hello, yeah, if this is your first time on support stack, this is not the usual format. Today what I'm gonna do is a slightly different version where it's just me talking through one thing that I've seen. If you like what you've seen, click the subscribe button in this video and you can also like the video as well. That would be very helpful. what I'm talking about today is...
we're seeing a lot, I'm seeing a lot more interest anyway in Fin's procedures. So procedures is the evolution of Fin tasks. If that's something that you've heard of, then they're the same idea. Fin procedures is like the version, probably version three of it at this point. And what I'm seeing is a lot more questions. How do we use procedures? How do we get them set up? What makes a good procedure? And I actually think that the starting point here should be, okay, what are you building first? So I'm creating,
this video to talk you through how I've created one of my ideas for my own website actually for my own intercom workspace and also to give some thoughts on what makes a great fin procedure and how to set that up
So you can see on my screen I've got a couple of points here this is just my little notion document and this is a bit dramatic everybody builds the wrong procedure first.
But what makes a great procedure experience? So what is it that makes Fin's procedures really effective is that they can be fast. So Fin can respond to customers in a couple of seconds. Fin can, there's no, there's less waiting involved. So there's no loading. There's no like, wait, my system's being a bit slow. So you can get back to customers really quickly. It also makes it very efficient for your customers and also makes it very clear.
So you can have procedures that are really clear for the customer. But as long as I think as you're designing them and always have an obvious path to a human. what I like about this, there should always be a route to a human. That's my own philosophy. I always think that customer support is a great skill set and we are always going to need humans inside the customer support organizations. And if you don't do that, you're just going to end up with really frustrated customers. So then.
Is this actually a procedure? questions around, okay, well, what are the things, what is it that you will need to make a procedure? So not everything has to be a procedure, obviously enough. Fin has a whole bunch of ways of interacting with customer conversations and procedures are just one type of, one tool in Fin's tool set. So typically a procedure will be great. You can have a process that's a good candidate for a procedure when it has multiple steps.
when it maybe has some branching logic in there as well. It can use data from other systems, although my example that we'll talk through later actually doesn't really need any other systems. It's just gathering information from a potential lead in this case. And it also has a structured conversation. So it's gathering information from the customer most of the time before moving on. And then you should also use it when you want consistent handling of the process as well.
So don't use a procedure. So here's some good examples of where you should not use a procedure. So don't use a procedure when you can't articulate a logical step by step approach. you, if it's sort of experimental how you approach these things, then keep it with your either keep it with Fin, but more likely keep it with your human teammates. They're going to be the ones who can bring their creativity to it and
later on start to document the processes in a more structured, formal way. Don't use a procedure when you have a Knowledge Hub article that will answer it perfectly well. If it's just a how-to or an informational question, then your procedure is not the best route there. Don't use a procedure when Fin's Guidance also handles it well. So for example, maybe it's picking up attributes from
user attributes and then you have guidance to tell Fin how to integrate with people on those user attributes and also don't use a full procedure when a standalone data connector does the job. data connectors are incredibly powerful and can be used to answer questions pretty effectively and also Fin will sometimes, I've seen it happen, sometimes chain together multiple data connectors even outside of task if it thinks it can use it.
So those are some ideas about when to use procedures and when not to use procedures. Procedures, they're just structured processes and instructions that give Fin the ability to do some pretty interesting and pretty complicated jobs. I would say it works really well if you have a large amount of data that you would want to quickly get from a different system.
pull it in and then use it to answer a customer query. But it always requires a lot of guidance and steps to interpret the data for Fin as well. So I'm gonna show you the example. I basically, talked out loud to a combination of Claude and ChatGPT as well. And eventually got to the point where I was defining this. So basically what I realized was I would like to have
as a lot of us do on my own website, which is customer success.cx, I want to set up a lead qualification system so that people can get the right kind of help from me, depending on what they need, but without always having to come to me one-to-one. So I've got this little document. And so what I did was I talked through it with Claude and with ChatGPT and I'm actually going to make a skill that you can use.
and I'll post a link to that in the video below, down below, that will help you go through this process and talk it through. So it talks about the problems and why I think it's important. The qualifications take my time. They don't respond immediately to the potential leads. And then I also want to make sure that they understand what it is actually that I'm able to give and not able to give. And then it talks through like,
what I always want and the disqualifiers for people I just don't work as well with. And so, yeah, it's all these kinds of details. then it also records like, what are the attributes we're gonna do? So what's the information that we're gonna process here in the procedure and say, okay, for example,
If they have used tasks and procedures or they have data connectors, then great, they're an advanced person. If they have Fin enabled and lightly configured basic, or Fin is not enabled, then it's not enabled, it gets recorded there. It's the team context, the number of people who they have using Intercom, and that would be from a customer support perspective. And then the availability. So I don't have a huge amount of availability in 2026.
but later in the year I'll have quite a bit more. So I don't want to set people up for disappointment. yeah, so that'll all come together. I haven't built this yet. I'm gonna build this on a later video.
So like I said, if you do want to hear more about this, then subscribe to this YouTube channel or also go to my daily email list, week daily email list, which is customersuccess.cx/daily.
That's customersuccess.cx. So hopefully this is a useful overview of building or not even building yet, but deciding on your first fin procedure or your early fin procedures. What makes a good procedure? What makes a don't start this yet procedure? And also an overview of an example of how I've talked through setting these procedures up. Like I
I'll create a skill and pop it in as a link below.
The other thing to mention at this point is I've got a new email series called the five mistakes you're making with data connectors and how to fix them. And you can see a link to that in the below as well. So that's customersuccess.cx/5mistakes. That's the number five mistakes. And that will lead you through five.
emails, one email per mistake with a description of what the mistake is and then a recommended approach and one to do every day, not overwhelming, but if you're using data connectors, this is a really helpful resource based on my experience of implementing probably around 30 data connectors at this point, 25 to 30 somewhere around there and mistakes that I've made and I would really like you to not make.
I think the maths on it is basically like if you solve god if you solve two more conversations, you've probably made back the price of the email series. That's kind of worth it. So that's it. So that's customersuccess.cx/5mistakes five mistakes. Yeah, thank you very much. Like I said, if you enjoyed this video, subscribe and I will see you in the next episode of support stack solo, which is episode two, where I will be going through the process of setting up.
first this procedure and showing you what that looks like. All right, bye!