Map your first procedure

To get the most from this lesson, make sure the following are in place.

• Fin deployed: Ensure Fin is live and handling customer conversations so you can see where procedures will have the most impact. Learn everything you need in the Launch Fin course.
• Understand the procedure builder: Familiarise yourself with how procedures work and the tools available in the builder before planning your first one.
  👉 Take the lesson

So we've seen how procedures work and how the building blocks come together inside the builder. Now at its core building a procedure is just translating one of your processes into something that Fin can understand. So quick check before we go any further. If what you're trying to automate is actually quite simple or if you feel like you know it inside out then you probably don't need to watch this video. You can just jump into the builder and get started. But if it's a bit more complex or if you feel like you don't know it that well then taking a little more time to map it out is actually gonna make things a lot easier. Now a mapped out process can look something like this, but let's zoom out for a second. How do you decide which process to map in the first place? A good place to start is inside Intercom. Under recommendations you can see data gaps. Now these are processes that come up a lot and could be resolved with a procedure. This is gonna give you a solid starting point. But don't just rely on that. You should be talking to your team asking them what are the most repetitive things you're dealing with, which ones involve making updates in multiple systems, and which ones would make the biggest difference if it was off your plate. Between the recommendations and those conversations you're gonna end up with a short list of potential processes and from there you can sense check each one. So how often does this happen? Higher volume usually means higher impact. Who does it apply to? Is this affecting most of our users or just a small segment? What systems are involved? More systems usually means more complexity to manage. And how complex is it from end to end? More steps in edge cases equals more effort to build and maintain. Now these questions will help you identify where the biggest opportunities are. Now it's often tempting to pick the one with the highest return on investment. However these are usually the ones that are the most complex and the hardest to build. So it's really important to balance the impact that it could have with the effort it could take to create. And I'm gonna let you in on a little secret. The teams that we've seen have the most success are the ones that started small. They got something working fast and then they built and iterated from there. So when you're choosing your first use case it doesn't have to be something complex. A great place to start is with a simple structured workflow like troubleshooting. For example a customer reports an issue, you gather a few details, check what kind of problem it is, guide them through some basic steps and if it's not resolved escalate with the right context. Now these kinds of procedures just follow a simple pattern. You collect information, branch and responses, resolve or escalate. They don't require any data connectors just really clear logic and good instructions. But on the other end of the spectrum you might have something like subscription management where you're checking account data, pulling in information from other systems, and potentially taking action. Now both are valid but if you don't have access to data or technical resources these simpler flows are a great place to get started. So once you've chosen which use case to start with, it's time to map it out. And the best way to do this is break up the mapping process into different parts. Green is what the customer says, yellow is what Finn needs to do, and red is where data comes in from other systems. And from there you just map everything out. You can use an LLM to sketch something like this out in minutes and seeing the entire process from end to end makes it much easier to identify a simple v one to start with. Remember you don't need to get the whole thing right on day one. You just get started quickly and learn as you go. Looking forward to our next video we're gonna be showing you how to turn your map into a working procedure. In the meantime I recommend taking your map and using an LLM to draft a rough version of the procedure so you have a good draft going into the build phase.