Jump to content
2600Hz Community

Idea - Invisable unicode characters to track menu usage?

Rick Guyton

Recommended Posts

A couple of our client's systems are getting quite large and we are running into an issue. That issue is we frequently can't figure out how a particular call was routed to a particular phone/user/mailbox. To dig further into this we need to put a ticket in with support to have the logs pulled. This works, but it's not optimal. So, I considered putting caller ID prepends into each menu options. But, some of the menus get 3-4 deep and that's just too many prepends, users would have trouble seeing hte actual caller ID. Then it occurred to me, there's a few zero width unicode characters. I could prepend with those... But if I do that, am I going to break anything? Has anyone done this before?

I was considering using:







Edited by Rick Guyton (see edit history)
Link to comment
Share on other sites

17 minutes ago, Tuly said:

There's a new option in each prepend, To either ignored the old ones or to add to the old prepends,  I'm not by a computer so I'm not sure what the options are,  but look at the prepare box, 

Oh, good point, I didn't think about that. That'd make the situation a lot better.


But, I'm still curious about those zero length unicode characters though. It'd be nice to be able to track this by looking through CDRs without it popping up on user's phones.

Edited by Rick Guyton (see edit history)
Link to comment
Share on other sites

49 minutes ago, mc_ said:

There's a new callflow action, "set_variables", that you can use in Kazoo 4.2+ to set key/value pairs on the call. These will then exist on call events and the CDR under "custom_application_vars". This is probably the saner way to accomplish your goals.

Man, everything I want is always in the next release. :) Not sure if that's a good or a bad thing. But, yea, that seems a lot more sane a way to address this. I'll wait. Out of curiosity, can you append to existing values? For instance could I have a key "menus" that's set to ":LocationAMainMenuOpt3", and then later append ":LocationBMainMenuOpt4" to that?  This way later, I could split on ":" and know the client originally called location A and punched a menu to go to location B and pressed option 4 there as opposed to calling Location B directly and pressing option 4?

Or maybe (even better) can I assign a key like "Menu_%Timestamp%"?

Edited by Rick Guyton (see edit history)
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...