Staff Merge Tags

Common use-cases

If you want emails to go out from the CSR that's on the Policy screen, you need to:

• put{|staff:csr,policy|email|} into the FROM email field

• put {|staff:csr,policy|name|} into the FROM name field

• If you don't have the option to use {|staff:csr,policy|email|} for the FROM email,
  reach out to your CSM

Old staff tags (Client Screen only)

The tags you're probably used to seeing now are:

• {custom_custom_csr_email} - Client screen CSR email

• {custom_custom_csr_name} - Client screen CSR name

• {custom_custom_prd_email} - Client screen Producer email

• {custom_custom_prd_name} - Client screen Producer name

• ... the rest follow the same format for Phone number, extension and title.

This old format is the first one we had working. You could copy this into the "FROM" fields for emails, and it would work. These are always pulling from the Client Screen.

These still work, so you can keep on using them.

 

 

New staff tags.

• {|staff:csr,policy|email|} - email, for the CSR, from the Policy

• {|staff:csr,policy|name|} - name for the CSR, from the Policy

• {|staff:prd,policy|email|} - email, for the Producer, from the Policy

• {|staff:csr,client|email|} - email, for the CSR, from the Client

• {|staff:prd,client|email|} - email, for the CSR, from the Client

So, basically when you break it down, this is it:

• always starts with {|staff:

• after that, you specify the staff type, csr or prd, followed by a comma.

• after that, you specify the source screen, client or policy, followed by a pipe |

• and you end it with the field, ex: email, name, ext, custom1, title, signature_image...

• ended with |}

Activity Staff

As with Policy and Client staff merge tags, the same structure works for "Activity/Abeyance" staff, for example: {|staff:csr,abeyance|signature_image|}.

Note: Trigger type needs to be set to “per Abeyance”, it doesn’t work with “One time send”.
This might not be available on your BMS, please check with your CSM for more information.

 

Branch defaults

If the Branch Management system is set up in the account. You can also pick separate "Default CSR" and "Default Producer" entries for each branch.

So, if their customer data includes branch codes, and it comes down to using the default CSR, it will first attempt to look in the Branch data, using the branch code on file.

Fallback functionality

There is a fallback system in place for the staff tags, to make sure nothing gets sent unsigned.

• If no CSR is present on this customer, falls back to the default CSR

• If no CSR is found, at all, fall back to account info (profile name and profile email)

• If no Policy CSR is found for the policy, first it falls back to the Client CSR.

So the fallback progression is:
"Policy CSR" -> "Client CSR" -> "Branch Default CSR" -> "Default CSR" -> "Account Profile".

NOTE: If the customer branch has a selected "Default CSR", then that's the "Default CSR" in the previous progression.