Now, think of these tags as placeholders for information. Anywhere you insert a tag into your script, you’ve just told the system to direct ‘x’ (tagged) information to ‘y’ (tagged) location in your script (we’ll go over how to display those tags in your script
next).
This means you can
set up your lead list fields (or make your API connection to the server or app containing your lead information), then add tags to your script that reference those fields. Now your lead-based tags are ready to be referenced and/or updated once your agent is on the line with a lead and interacting with the script.
And if you’ve added call- or chat-based tags to your script, you’ll find that when a call or chat comes in or goes out, all the information you want to know about that call or chat is already being collected from the moment the system makes or registers that call or chat.
Your custom tags become available the moment they’re generated by the system, and once you’ve referenced them in your script, they immediately begin capturing data the moment the agent begins checking boxes, taking notes, making dropdown menu selections, or interacting with the script in any other way.
The tagging itself largely happens behind the scenes, and the data-capturing part happens when you insert tags into a script and let the system or the agent dynamically populate those fields with information gained while on the call or chat.
Please note that agents will only see tag-based data appear in the script while they are on an active call or chat. If they’re simply previewing a script and they are not on an active call or chat, they will see an empty space in the script where the tag data is meant to populate.
The same holds true for the Render script setting in the admin interface; a rendered script is not connected to any active call or chat, so you won’t see anything but a blank space — that is, a tagged data placeholder — during the script creation process.