Simulate a 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. Learn everything you need in the Launch Fin course.
• A built procedure: Create a procedure that is ready to test. 👉 Take the lesson.

In this video, we're going to explain simulations and how you can use them to test your procedure at scale. We've seen how you can use the preview to spot check individual parts of your procedure as you build it, but simulations take it further. They let you test the whole thing from end to end across multiple scenarios all before it goes live. When you click into the simulations tab, you can see that based on our procedure, Fin has actually already generated some simulations that we can use to test it. You can see they mirror the main paths the customers take in the procedure. Let's take a look at one now to explain how they work. So at the top, you've got the scenario, the customer's name, email, what they're trying to do. And below that, the conversation plays out, allowing you to see a fully simulated back and forth between the customer and Fin. Now, one key thing to note here is when you see thinking, you can expand it to see exactly what Fin was trying to do at each step. And being able to understand what Fin is thinking and trying to do makes it so much easier to debug its behavior. Now, once the simulation finishes running, it gets evaluated, highlighting what went right and what went wrong, along with an explanation and a suggestion so we can go ahead and fix it. Now, the simulation we just looked at was one that Fin suggested based on the steps of our procedure. If you recall, it was all about enabling physio clients to kind of reschedule or cancel their appointments. So a good scenario to test might be what if a customer tries to reschedule their appointment, but their appointment has already taken place. This is the exact type of edge case that we want to test and account for to make sure that the procedure can handle it properly. So we'll click create new simulation. First, you'll pick who to simulate us. Now you should use a real customer from your system, but since I'm working in a test workspace, I'm gonna use a test user. Next, we write the opening message. This is what the customer says to kick off the conversation. And then underneath, we'll add some additional context. This context box is where your scenario really starts to come to life. Now we've deliberately made simulations quite strict. Your simulated customer won't guess or fill in the blanks, so whatever you want the customer to know, you really need to spell it out here. The more you put in, the better the simulation is gonna mirror a real conversation. Okay. So we know that the customer wants to reschedule a booking, but we wanna see what Finn does when the booking has already taken place. To set this up, we go into the data connector responses. This is the day that a Fin will actually see and change both appointment dates to the start of April. Then we update the simulation time to April tenth. So now those appointments have already come and gone. We've got a customer asking to reschedule something that's already happened, and we get to see exactly how Fin handles it. Now for the evaluation. This is where we set up rules to check whether the simulation was successful or not. We're gonna set up two. First, that the rescheduled booking data connector was not triggered because if it was, Fin would be helping them rebook an appointment that's already happened, which we don't want. And the second criteria will be a message, and we're gonna want Fin to tell the customer that their appointment has already taken place and that they need to book a fresh one. You don't need a long list. Just two or three criteria to cover the key moments is actually plenty. Okay. Let's run this simulation. I'm gonna speed this up, but as you can see, the full conversation is actually playing out, and Fin is going ahead and rescheduling the appointment, which is exactly what we didn't want to happen. And when our simulation finishes, you can see that both of our evaluation criteria have failed. Now this is actually a good thing. This is exactly what simulations are for. We set up a scenario, check whether Fin handled it correctly, and found out that it didn't. So now we need to update the procedure in order to handle this. So we'll go back into the procedure, add some more instructions here, telling Fin that if the appointment date is in the past, don't reschedule it. Instead, switch to a different procedure that handles booking a fresh appointment. And because we changed the procedure, let's go back and add a third evaluation criteria to the simulation that in order for it to be successful, Finn should switch to another procedure. Let's run this simulation again and see what happens. As you can see, this time we got all green. So it's actually that last part that catches a lot of people out. Every time you update a procedure, existing simulations might not match anymore. So make it a habit when your procedure changes, check your simulations. Otherwise, you're just gonna be testing yesterday's version. So that's simulations. There how you go from, I think this works to, oh, I actually know this works. You can use them to check every detail so you can go live with confidence. And the more scenarios you cover, the fewer surprises you're gonna get when you go live.