Hello legends. In this video, I'm going to show you how to build out your own customer support agent in Nan. We're going to be building uh this workflow, or rather I'm going to be going through this workflow with you. Um I've actually got another video that I made recently building out something like this step by step. So I'll link that in the description of this video. But for this video, I want to show you an automation that's going to be able to pull in all of your tickets from a tool like Zenesk or Gorgeous or even Freshesk. So, if you're actually using a customer support CRM for your business or if you're an agency and you're actually trying to offer these services for different businesses, um this automation is going to be able to pull in ticket information uh and every single comment on that ticket. So, fresh tickets or existing tickets. It'll be able to retrieve all the ticket information and then it has um a very basic starting point where it has two separate routes. for open tickets. It's going to go across to a responses agent which will then generate a response for that ticket and send it directly back into let's say Zenesk for this demo we're going to be using. It's going to send it back into Zenesk as an actual response. So I've got a demo over here where a customer is messaging asking about uh specs for a product. This is an internal note just doing some testing over here. And then finally, this is an example of a live reply that goes back to the customer. So, when the customer emails in um or sends an SMS or whatever communication they do using Zenesk, uh that's going to be picked up with that automation and then we're going to be able to respond back. Um initially, I would just suggest responding back with internal notes because it's a lot safer. You're not going to, you know, in case the system isn't super accurate or has some errors, you're not sending it back to the customer directly and your agents can still kind of come into here and just, you know, have um like a co-pilot explaining what to do for the next steps or generating responses. Um, but once you are ready, you can actually just add responses directly back to customers. So they can get an SMS back onto their phone, they can get an email into their inbox, and um, that's all possible with this route over here. And we also, uh, log all the responses into a Google sheet. So one thing that I find is it's actually really good to build a Google sheet where you can have every single interaction logged from the agent that you're creating. So instead of going into Zenesk or gorgeous and like flicking through all the um responded to tickets, you can just have a really high level overview here of exactly what's going on. So you're going to be logging the date of the ticket, the ticket ID, the subject, the actual body, so the entire message and all the contents and everything that's associated with that ticket and then the response generated by the AI. And this way once you get, you know, 10, 20, 50, 100 tickets logged, it's easy for you to just kind of flick through this Google sheet and see the all the entirety of the responses. Uh and the second route is going to be going through solve tickets and then generating an FAQ from them. So one thing that I'm finding working with customer support teams is hey we want to build a knowledge base. We've got you know this set of FAQs to start with but um a lot of the information is actually contained within you know specialized human agents or humans that you'll have to go into Slack and ask them. We have to ask them in real life or you might have to watch a YouTube video to find a specific part and then be able to uh respond to the customer. So this final part just goes through solve tickets and then generates an FAQ uh based on that entire ticket. So uh we're asking this agent to essentially look at the entire conversation whether it's one reply or 10 replies and just generate a succinct FAQ question and answer pair that would essentially capture the entire ticket and then we're logging that into Google sheet as well. So it's in the exact same sheet but just in a different tab and this is the FAQ tab. So, pulling in the exact same information, date, ticket ID, subject, ticket body, then the FAQ that's generated, and then what you would do is just come into here every Monday morning at 9:00 a.m. review the previous week's tickets, look at whatever FAQs you have, and then you would update your either your rag database or your um your website. And actually, for this agent, what what we're doing here, and one thing that I'm actually doing a lot recently, um is I'm not building a rag database. I'm not using Pine Cone as a database. A lot of people that I work with have websites that have heaps and heaps of pages and all the product information is on the website. Um, a lot of troubleshooting articles like everything is there. So instead of building out a rag database and taking all the information that you have from your website anyway and then putting it into a pipe cone which is you know that means you're now double handling the information um we're using the perplexity API search and we're restricting domains directly to the website in question. So that means you're getting an AI powered web search directly to the website of your choice. So your your own e-commerce website or your client's e-commerce website um and then you're building out the knowledge base from there uh live. So you just maintain your your your support articles on your website and then this a like API call literally hits that page. So yeah, it's a very easy way to get started. It's very accurate way to get started. It also means you don't have to double handle information. Um, but yeah, so in this video, we're going to be getting a customer support agent that's going to be able to respond to all tickets. Uh, and like we mentioned, either as draft replies or public replies directly back into the customer's inbox. Um, it'll create FAQs off of solve tickets and we'll log everything in Google Sheet. Now, this is a very I mean, this workflow end to end is going to work. So, I'm going to show you how to hook it up into Zenesk and actually get responses generating like this. Um, but be mindful it is a beginner workflow. Like you can actually take this today and start generating responses and it's going to work. Like the setup time for this will be 10 minutes. go to my gum road, download this and install it. Um, but you've got a lot of opportunity here. So, throughout the explanation of this video, when I go through each node, uh, step by step, I'll just explain to you firstly what you have to change to make this work for you, but also what you could do as a step two and how you can improve this and enhance this. So, um, yeah, that's what we're building out today. We're building it out for Zenesk. I'm going to show you the Zenesk side of things as well, how to create the web hooks and triggers and everything. But these principles will be applied across to Gorgeous and to Freshesk as well. So if you're using different CRM tools or you know even ones that are not listed here um this entire like the concept of what I'm teaching you are going to be applied for all these different CRM tools. So the first thing we're doing is we need some kind of entry point into this agent in order to make it run. And uh one thing that I do when I'm creating these workflows is um yes we'll have a web hook uh that accepts a payload that comes across from our ticketing tool. So we're going to be using Zenesk as an example in this case. Um, and all we're doing is we're creating a trigger in the Zenesk back end that says every time we get a response from a human, so I mean like a new ticket from a human, so like brand new tickets or if we get a response like when they respond to us after we respond to them, um, anytime we get that kind of activity onto a ticket, we want to send the ticket like the information uh across to our nan agent so that the agent can read the ticket, create a response or create FAQs and then kind of complete the other actions. So the first step for that is we have to generate a web hook node and we're doing that within n and um yeah all we're doing is we actually have a test URL and production URL. For this instance we're using test URL so we can actually see all the nodes fire off and see how everything works. And I manually adjusted it to make it a post request. So you can make this any type of request that you want. For this specific node we want it to be post because we're sending information across from Zenesk across to here. Um and these are the settings we're going to be configuring within Zenesk. So the very first step is for us to go into our admin center. Let's go admin center. And there's two things that we need here. One, we need a web hook. So we need some kind of like phone line connection between Zenesk and the N8N agent. So that's called a web hook. And secondly, we need some kind of like way to tap Zenesk and say, "Hey, there's a new ticket. Send this information across." And that's called a trigger. So the first thing we're going to do is actually search web hook. And let's create a web hook first. So we're creating this. Let's just go to create a new web hook. We're going to be um making that web hook fire off using a trigger or automation. And let's just call this N8N web hook. Be a bit more creative here, a bit more specific. Um but this web hook we'll be using for every single ticket. So for brand new tickets into the inbox, for tickets that are recurring, or for solve tickets. So everything's going to this one agent endpoint. And for our endpoint URL, we're back in nan and we're just going to be copying this test URL for now. So, let's go back into web hooks, paste it into here. We have the post method. We're going to be using JSON. Uh, everything is good for here. For now, we're not going to be doing any authentication, but we could if we wanted to make this connection a bit more private. Now, let's go to test web hook to just give this a demo and see how this works. So, just go to your dropown, select custom test, and now you can edit your payload. The payload that we're going to be sending is ticket ID. And then we're going to have some arbitrary ticket ID here. And that ticket ID, just so you can see, is essentially this this over here. So this is ticket number 110. That's the ID. The ID is 110. Um, so I may as well just send this into here. So 110. And now when I hit send test into here, the information is going to come across to my agent. So this workflow is going to be generating now. Uh, and just to refresh us, this is basically saying, "Hi guys, what are the specs of the hot tap?" And then we have a response over here. So it might kind of buckle our agent a little bit. Um, but we're going to be seeing this information directly in our agent. So I'm going to go to test workflow. And now the test web hook is going to be receiving events. And across in the web hook, I want to hit send test. Let's hit send test. We'll have a response back saying that the request was received. And across in nan, we've hit the first few API calls and now we're plugging away through here. So, okay, let's let's wait for this to finish. All right. Awesome. And now let's start digging in. So, the first node we have is the web hook node. And what we just defined um in that in that web hook step is uh to send this package of information across. So, we're just getting the ticket ID. Now in a lot of API platforms when you're sending across like um the ticket ID or customer ID or company ID associated to that ID is actually a bunch of different information. So using different Zenesk API calls we can just feed in the ticket ID as the as the main search um the searching tool like the searching criteria and then we're able to pull out all the information against this ticket. So that's where we're sending the ticket ID and that's the only thing we're sending from Zenesk and then we're plugging the ticket ID into this first API call here. So this API call what you have to edit is you have to insert your domain name into here. So you can just look at this um this the structure of this specific URL and when you're inside zenesk your URL will have something similar. So let's say your store is called bubbles then it will be bubbles.zenes.com. So then all you need to copy and paste out of here is just put bubbles into here. Um then we're dragging into the endpoint the actual ticket ID. So then our actual API call is our domain.z.com and then/tick110. And this is going to return a set of information for us which is including the ticket subject and the very first comment from the customer. Um but the Zenesk API actually there's a bunch of different APIs that we could use. The the second API is um it looks very similar but it has the um ticket ID and then forward/ comments at the very very end. And that forward/ comments just means um hey zenus give us the actual entire comments from the ticket um not just the very first ticket information. So that's just how Zendesk is set up. maybe gorgeous and fresh freshes will be different. Um but that those are the two endpoints that we're using to capture all the ticket information and then we have for credentials I've just authenticated my zenesk um my zenesk account which you can just uh create your credentials in zenesk you'll have to get your API key your domain name um and then you have to put your actual user account email address into there and then it's going to authenticate pretty easily. So I'm going to skip over that step. We're sending our headers of content type and application JSON. And then for our body, we actually have an empty body because we don't need to kind of restrict any return data for us. So all we're really looking for is um the entire package of information from Zenesk. And then if I just zoom into here, we can see that we see the uh URL of the ticket. So it's the 110 ticket. Uh it came in through the email channel. So let's say you actually have email and SMS and uh Messenger and anything else. You would use the channel to actually split off different routes for different agents because the response you generate for an email would be different to this the structure and style of a response you generate for an SMS. An SMS might be just short and snappy like, "Yep, we got that in stock." Whereas an email might be like, "Hi, Bart. Thanks for your email. Yes, we have that product in stock. Thank you very much, Bubbles, you know, bubbles.com." Um, so that's one thing that you could actually do is just look at what channel the the the email is coming from and then set up your AI agent to respond accordingly. You got the the information from the customer, their name, their address that you can personalize their email, and then some other data over here. Um, but the key thing that we're doing is we're pulling in the information across these two nodes. Uh, and it's got the same setup over here. So, there's just uh application JSON, and there's no actual body parameter. Um, but we we process the entire ticket. So, using this, we're actually going through both of the previous nodes and we're pulling out all the ticket information that we need in order to plug into our agent. So, it has um the ability to read the ticket and actually generate response or gen generate FAQs. And uh I've got a pre I've got it filtered. So, all the responses we get um we're filtering out public comments. So, in this spot over here, so public comments um we we only want public comments. We don't want internal notes. So, anything that is in yellow, we don't actually want that. Sometimes a team might be asking questions between themselves and it might have some information you don't want the agent to see because it's not part of the response. Um, so all that this API call is going to return is just the um the responses from customer and from the agent. And in order for us to format the response correctly, I've got the support staff ID over here. So support staff ID is just the user ID. Uh let's say you've got one account in Zenesk. This is the user ID of your staff member. Um you might need to edit this code to actually include include an array of uh staff ID. So if you got a team of 10 agents, you want to include all those 10 agents here because when we're filtering through the comments, um each comment actually has a specific author ID. So uh a user like the end customer will have a specific author ID and then you're able to associate um on the right hand side over here. Okay, the role was customer and they sent this and then the role was staff member and they sent this. Um so that's actually what we're trying to do uh for our setup is just distinguish between RO and customer. Um, I think for my example, it's a little bit bad because I'm using um a bunch of email addresses associated to my account, but you will normally see RO customer as the first message and then roll uh staff member as the responding message and then so on and so forth. Um, and just to give you an example, uh, I'll tap here the here's the key specs. So then we have the author ID of this this specific comment over here um, is the person that we actually want to use. Actually, my case, this might be a little bit wrong. That's the author ID I want to paste into here. If I just test this step again, it should pull it out properly. Yeah, there we go. So, I actually had the wrong step uh the wrong value defined. So now I have RO customer which is the first message from the user and then I have RO support staff and that's thanks to yeah this variable here and in case you want to find it you can just go through your API responses and see all right which one is actually from our team that's the author ID from the team um and that's how we're able to distinguish here. So once we get that actual uh pro like process the entire ticket so we get the JSON of that we then flatten it into markdown because we're not able to actually insert um the JSON into the AI agent. So once we test this step we'll get the exact same thing that's here but broken down into one variable called ticket info and then we're just using like markdown format. So double hashtags for titles. Um we're bolding up customer. We're kind of putting some um some structure into this to to basically to the AI so we can distinguish between messages from um messages from users, messages from staff members. This little switch node is just looking at the status of the ticket. So we're just pulling in the status from one of the previous nodes. So for example, if we go to HTTP request 3, which is what we're using here, we go to ticket.st status. So over here we have open. So in your account you might have a couple different statuses. new, open, pending, solved, and closed. So, I'm just looking at anything that is um like open or pending or whatever you want to look at here. Um I'm just saying if it status is open, that means the ticket is ready for us to respond to, and we're taking the first route. If the status is solved, then that's ready for us to actually examine and create an FAQ. So, we've got these two routes over here. So, we have agent one and agent two. And then for agent one, I've got a very basic prompt as a starter for you. Um I'm pulling into here the uh flattened information from the ticket. So, if we go a couple nodes back where it says flatten, this ticket info is what we're putting into the user message. And that's how we're giving the context to the agent. And then over here, um, I'm actually doing a bit of a hacky job. So, the first thing is, hey, you're a helpful email assistant. Your job is to read a ticket and generate a response using the web search tool. Um, but the output that you are creating is actually a JSON output. Uh, and this is the exact body for the API call when you're generating a response for Zenesk. So, now's a good time to go across to the Zenesk API docs. And um yeah, so right now we're just looking at the update ticket endpoint, which is a put request with the uh forward/t then ticket ID. And if I scroll down here, the body of the ticket actually explains what we want done into the ticket uh sorry, the body of the API call. So we're looking at ticket. We want to add a comment. The body of the comment is this specific message. Is it a uh public response back to the user? Or if it was false, it would just be one of those yellow comments on Zenesk, which is an internal note. And then you can change the status as well. So typically as if you respond to um if you're responding to customers for this for the first flow of the agent, you want to set this to something like pending because pending is a status where it's waiting for the customer to respond back to us. Um but that this is exactly how you can like add tags to tickets, how you can trigger off different, you know, situations in your Zenesk environment or in gorgeous and freshes. Um so this body we're actually uh creating that within this agent response. So it's the exact same format over here. ticket comment body and then over here I'm just creating the structure of what I want what I want the response to be like hi there then we have some white space we have the response that we're giving to the customer which is the AI is going to be inserting here by themselves and then we have thanks and then your customer support agent so you would actually modify this to be exactly what you want the email format to be but keeping it in this uh structure means that when we're building the API call later on um it's going to be nicely embedded directly into the API so I'm going to go back into this in a second but once we get that response from the agent Uh we're in the code node over here and we're just parsing the response that we get to uh to basically give us the information we can pop into the API call. Um let me just hit this off one more time so we can get the full ticket information. So let's go send test. It's going to make it easier for us. Cool. So we're getting the response generated. And now in the code node we can see the previous response is just the JSON output of ticket comment the body all the information that we wanted for that ticket and then we're parsing it out. So we can actually just pull that variable directly into the API call. So now this structure looks a lot more similar to the structure that we see here uh where it's exactly formatted ready for the API call. And then if I just click out of here and I click into this API call. So this is another Zenesk API call. Once again we're putting our domain.z.com/ then the 110 is actually from the ticket ID we're we're um we're working with. Sorry for this. I'm just going to change this because I didn't uh bring it in. Ticket ID to the end of here. Now it's dynamic. Okay, that's perfect. So that's going to be ready when you when you guys download the flow. But there we go. It's going to be sending across to here. Um, and yeah, same same setup as before. Now we're putting a port because we're actually updating the information on the ticket. Um, we're not send we're sending the exact same headers application JSON. And then the body is just the uh stringify JSON which is the previous code node. So the most recent code node after the agent, we're just sending this entire package into this API call. And if I extend out over here, uh we have the body of the API call which is ready to go. And then that generates the response onto the ticket which we can see here. 1 minute ago we had the response. Hi there. Okay. So the formatting isn't coming through absolutely perfectly. I think somewhere along the way it just messed up. Um but yeah, you can see how this would work. You would just go into uh chat GPT and say, "Hey, can you help me with the formatting of this?" Um maybe the forward slash new lines are not not embedding correctly. And now we go into Google Sheets and let's see what's what's happening here. Unable to service your request. All right, that was strange. So I just literally hit re uh retest step and then it sent it across and it went through and then we had the uh most recent response here. So yeah, as you can see that now you have the ability to actually just come into this Google sheet and review the information that was sent across. So you have now ticket body. You might want to pass this to make it a little bit cleaner and neater, but the customer says a specific message. Um, we've got responses from agents and customers in here. And then we have the response that was generated. So then you might actually have a tab over here that just says um like checked or verified or whatever you want. Like so this is in testing and you want to make sure that this is actually going good or not. You might say yes. Uh you might say no. And then based on this feedback you might see okay out of 100 tickets there's only three nos. So this is actually good enough to go. Or if it's like 50% nos and 50% yeses you might go through and kind of look at all right what information is incorrect. Um, so going back in n one step back here, uh, we're using the HTTP node to actually hit the perplexity API. So the perplexity API is just using the chat completions endpoint. Uh, I've got it open, which is over here. So it's the chat completions endpoint. It's a post request. Then we have the body of the API call here. So just pay attention to this. So we've got model messages that we're sending across and across in our nan agent. Let me just scroll down a little bit. So I've got my authorization where I get the API key directly from my Perplexity account. um it has to be bearer and then the actual API key. But if I zoom out uh you might notice that this is a slightly different API or HTTP request node that you're used to. Um and that's because this is the latest version of N. So previously you can actually just generate the JSON and then input like a placeholder which is going to be uh which is basically defines what's the question we want to be asking to the perplexity API. So the placeholder is a dynamic variable that the AI agent would insert into the actual body of the API call. um we now have to do this kind of setup where uh for the JSON you just use the AI button. So it's like a button like this right over here and it automatically generates and then in the description you just have to explain exactly what the body would look like and then the agent will dynamically change that. So in our case we have the model which is sonar. Um we got this search domain filter which I'm using dual.com which is my e-commerce website and from the API call it's not actually listed in here. So it's just model sonar and then the messages that we're sending. Um, but if you scroll down, one of the other variables is actually search domain filter. So, search domain filter is really cool because you can literally just put your website information here or if you're using something like Zenesk and you have a customer support page, which for example is something like this. So, this is actually using we use Zenesk for my e-commerce store and we have the Zenesk support page extension and uh we've got like heaps and heaps of articles here that we created uh for people to be able to like troubleshoot their uh you know dual gear to get um FAQs on the gear to raise requests everything for all of our all of our products is here and we maintain this as a source of truth. So, um yeah, all we're doing is we're adding that URL into here. So, technically I could actually add the jul.com which is a sales page and then also the uh juler.com like/support page into here. Um, so this is exactly how you set that up. So you put your search domain filter into here and then every single question that we're asking using the agent is only going to be from our like from our actual web page. Um, you can actually edit the uh be precise and concise over here. So the system the system content you can change but the AI agent the parent agent actually does a good job of editing the response anyway. And then I have the variable over here which is question to ask. Um, and yeah, this is actually this is this is perfect. It works uh treat you don't have to create a separate pine cone or like separate rag agent. So that works perfectly and then we have yeah like basically whatever we had before. So we have the code node that passes the response goes into the API call and goes into Google sheet. So let's look at the second flow now. So for solve tickets if I go across to my web hook and uh I actually let me just find the solve ticket. So ticket 103 is solved. So I'm going to copy this and now let's give this uh workflow a run. So I'm going to go to test workflow. Go back into my web hook over here and paste in 103. I'm going to hit send test. And now the agent's going to be yeah generating an FAQ for us. So uh if I go through basically it's the exact same steps step by step. We pull out the initial ticket information then all the comments. We parse it. We flatten it. Um and then we have a switch router where we're using solved tickets. So in this condition or in this in this specific instance we met the condition of solved tickets. So if I go back to uh this step over here, we should be able to see the status. Okay, there we go. status is solved. And be mindful that it's lowerase. It's all lowercase. So status is solved, lowerase. And then the AI agent's got a very simple prompt again. Um, and yeah, ticket info. We're just bringing it in from that flatten node. So as you can see, we can just pop this open and it has all the ticket information that we had. So the subject, the information from the staff member, from the agent, whatever else we had over here. Um, and then we have a very basic prompt. And uh, I mean, what you would do here is actually figure out exactly what kind of reporting you want for all solve tickets. And then you would just build out this FAQ section. So, right now I'm like, "Yeah, I want the FAQ." Um, but you might also want like what was the ticket about? So, what was the the topic of um, you know, intent? Was it a general question? Was it an order question? Was it troubleshooting? Um, you might want to see like how many responses were on a ticket. If it was below three, this is a this is a perfect ticket for us to try and automate or create articles for. If it was above 10 responses, then this is a really troublesome ticket for us. How do we improve our experience earlier up the line so that the customer doesn't have to have so much friction down the line? So yeah, for this for the second flow, it's it's a really good starting flow for you to just see exactly how the system works. And I think to generate FAQs is a very very good starting point, but you could do a lot more with this. So yeah, this prompt would be a lot more comprehensive. You could say, create me a JSON output that actually has an FAQ. It lists how many comments were on a ticket. It figures out what was the um contact reason about um categorizes the ticket. And then you could possibly even have like an agent. So, not an agent, but like an API step like this where it's a put request where you're not actually updating a comment onto the ticket, but rather you're updating tags onto the ticket. And then within Zenesk, you're able to um generate some like Zenesk reporting in the explore dashboards. So, once you generate the FAQ, let's just see what that was. What are the opening hours and our open hours of from 3 to 3 p.m. to 6 p.m. So, that was a very basic ticket. And then we're adding the uh adding all that information just using the uh placeholders that we're pulling across from the different nodes. And if I go into the FAQs over here, we've got the FAQ that we pulled across as well. So yeah, once again, um you would build this out to be a little bit more a little bit more comprehensive, but we've got all the key ticket information. So when was the last update on that ticket, what was the ticket ID, what was the subject of that ticket, um the body of that ticket, and then we have yeah over here, uh what are the actual open hours, and then yeah, what are the actual open hours? And then from here you can have another column if you wanted to and just see and just say like reviewed and you can say like yes good FAQ or no bad FAQ and then you know one by one every Monday 9:00 a.m. just kind of go through here um and then assess is this good to go or should we you know change our website information or whatever. Okay. And now our final step is we have the web hook setting information into here but now we go into Zenesk and actually have a trigger that will uh fire off every time a ticket is created or a comment is added to the ticket. So, uh, to give you a starting point for that, let's go back into these, uh, this web hook. So, I'm just going to go in and create this web hook because it's ready for us to go. Um, so I'm actually still using the test URL for the web hook. Um, but what you would do is go into your web hook over here. Just go into production mode and just copy across this production. We'll just do this now actually. So, we just copy this across. Go back into web hooks. Leave without connecting. And we just made this nan web hook. So, I'm just going to go actions, edit this, and now into here, I would paste my production version. Just update this cuz it's good to go. Then for your N agent, you just have to be sure that you come out of here, uh, and you hit save and you hit, uh, you hit active. And now active means you're going to be using the production URL. So, uh, back in Zenesk, let's now search trigger. And I'm going to show you how to start building these triggers for yourself. Uh but the first one is you want to have um like every time a ticket is created or every time a ticket is responded to, you want to create a trigger that sends that ticket information across to our N agent. So like what we're doing there, putting the um ticket ID manually, we just want to do that automatically as well. So let's go N8 to N and go new ticket category. Choose whatever we want. And now for our conditions, we want to go on the uh ticket status. So or actually for us we want to go ticket is created for brand new tickets and we can now have an action here which says every time a ticket is created we want to do something to it. So what do we want to do? We actually want to notify by active web hook which just means that every time a new ticket is created we want to notify a specific web hook and that's the nan web hook we just created. And the body of this is going to be exactly what we had before. So ticket id and it has to be the exact same as what we were playing around with before so that it makes sense for the nan scenario and then the uh actual body of the uh request over here is going to be in commas. We're going to view available placeholders and now we're going to find the ticket ID. So ticket ID gives us the ability to uh dynamically insert the ticket ID into this little JSON over here. So basically we're saying every time a ticket is created send across um send this payload across to this specific endpoint and that's what we're doing with the test before as well. So yeah now we have this set up. So ticket ID equals the dynamic ticket ID of the ticket ID or of the ticket in question. We create this trigger and then uh that's going to be firing off for brand new tickets. And actually what you would create is another trigger now. So nan nan uh update ticket. So, let's go update dash ticket. Uh, leave it for notifications. Go into here and let's go ticket. Uh, where are we? Ticket status. No, ticket is updated. Um, and you want to only fire it off for the condition where the current user, the one that actually updated the ticket. So, it can either be updated by our agent like the support staff or by the customer um is end user. So now this is saying that every time a ticket is updated with the comment from an end user which is the you know the customer that's emailing us we also want to fire off that ticket into the N agent because that's an opportunity for us to reply. So category we're going to go notify by active web hook n web hook the exact same one we had and now let's build this thing out just like we did before. So quotation marks ticket ID then here we put this and now we want to find that variable again. So, we're going to be scrolling down until we find uh ticket ID. So, let's copy that. Let's paste it into here. Awesome. So, now ticket ID. Uh and then we have the dynamic ticket ID of that ticket. Let's create this. And now, every single time you get an email, so a brand new ticket is created or you actually get a response from a customer, uh both of those tickets are going to be sent across to your N agent. And the final trigger you want to create is NAN solved. Oops. N AN solved. And for this, it's going to be the ticket status. So ticket status is solved. And now when a ticket is actually changed to solved, and I think uh change two is better. Um cuz it's only going to be firing off once. If you have ticket status is solved, every time there's an action on that ticket, like an update that we're doing with the tags, it's going to trigger it again and again and again. It's going to be a loop. So you want this to fire off only when it's changed to solved. So just that one time. Um, and same action because we're now actually notifying, we're going to be actually going through the solve ticket and generating some FAQs or doing our other reporting onto here and the exact same thing. So, we have ticket ID and then we have quotation marks and ticket ID. I had it pasted from before and create trigger. And now every single time you get a message or an update to a ticket or you have a self ticket, they're all going to be sent across to your AI agent and the agent's going to be um, yeah, responding to tickets or actually generating some reporting for you. All right, guys. Thank you very much for watching until the end. Um, if you're here at this stage, can you please drop a like on the video so YouTube can actually push this out to more people? And if you're going to be using this workflow, drop a comment below and just let me know, "Yep, I'm going to be using this and here's some additions that I'm making as well." All right, thanks guys. See you.