0

We have a system that allows a customer service representative(CSR) to create a note on a customer. Sometimes these notes are very similar in nature or wording.

I am programming a few forms that will allow the CSRs to pick common notes from a drop down. They may also go in and create their own notes that will be available in the drop down.

We want to have the notes be semi-programmable by the user. So if we want a note that says:

Customer 123456 burped on the phone.

The programmable version that the CSR will be editing/creating will be

Customer [CustomerNumber] burped on the phone.

From this point on we'll call [CustomerNumber] fields.

When the CSR either loads the note form or chooses the quick note the note form will see that the quick note contains a field and prompt the user or auto fill the data.

If I was to provide these fields to the CSR to use in a quick note editing form, and these fields were select-able from a drop down, what would I call them that would be user friendly and self descriptive?

2
  • The first thing that comes to my mind is Field tag, a tag that represents a field. Oct 1 '15 at 14:38
  • Only thing that comes to my mind is input, input fields, or input selectors. Unless you can broadly categorize all the potential fields then you could give them a descriptor like 'Profile Data Fields' or something.
    – DasBeasto
    Oct 1 '15 at 14:52
1

You can either use 'tags' or 'parameters'.

But whatever you choose, try to test it with a couple of CSRs, and see if they understand it.

My guess is that most of them will not bother to mess around with these. From my experience, CSRs tend to be focused on their current task, trying to end the call as shortly as possible.

1
  • After some debate I think tags would be the simplest. The word tag is used for many user-oriented functions in programs and such. Thanks!
    – Elias
    Oct 8 '15 at 14:37
0

I know for at least certain ITSM systems, these types of values are referred to as fields. Generally speaking, every CSR is familiar with populating the "fields" of a form, so it is possible that this connection is already made in their head.

So, if the userbase is accustomed to these types of systems I would have no problem calling them "Field References" or something like that. Another angle to take on this would be to focus on the context from which this data is gathered. Is the Customer Number coming from their profile or the ticket itself? In these cases, something like "Ticket Values" or "Customer Values" may make sense. I think context heavily matters here because the userbase is a far cry from say standard public end users.

0

I believe the term "mail merge" and "merge field" or "merge tag" as popularized by MailChimp makes sense for your use case.

Mail merge is a software operation describing the production of multiple (and potentially large numbers of) documents from a single template form and a structured data source: it fills in a form letter. The letter may be sent out to many "recipients" with small changes, such as a change of address or a change in the greeting line; these are represented by form fields or placeholders in the template.

https://en.wikipedia.org/wiki/Mail_merge

This is typically used for mails, which is very similar to notes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.