cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
942
Views
0
Helpful
4
Replies

Updating Prompts By Telephone

Keith Joel
Level 1
Level 1

Hi Folks,

     First of all thanks for your time.  I've searched around the forums looking for an answer to this but the best I can come up with is a recording script which still requires the customer to go into the application and update the prompts via that.  Basically, what I'm looking for is a way for customers to update a prompt quickly via telephone that will play prior to queuing.  Currently I've got a basic queue in place with a generic welcome greeting.  The customer is using CCX for as a helpdesk and they would like to quickly pre-empt the queue with outage notifications etc.  Is there a quick and dirty way to do this with contact centre or am I going to need to send the caller through a voicemail call handler first? 

Thanks,

Keith

4 Replies 4

kartik.bhatia
Level 1
Level 1

Will you be willing to change the CRS Script every time you record a new prompt?

There is a Recording start stop node in the CRS Script Editor, these can be used to record a prompt via a telephone.

However the recording will get saved with a different name.wav. This new .wav then must be updated on your queuing CRS Script.

No, that's the point.  For ease of use by the End User I'd like the customer involvement to be very minimal.  I'm just going to route the initial call through a voicemail call handler then to CCX.  That way they can just update the greeting on the call handler to notify callers of outages etc.  I find it hard to believe that a system that is so capable can't do something so simple.  I'm sure customers ask for this all the time.  Thanks for your input.

Hi Keith, the option to upload a recorded prompt using the Telephone is quite straight forward using a simple script.  You can then control this by enabling the Parameter option against the script prompt variable (if configured as a string) to control when Notification messages are played, from the Application Management page.  We use our own (BTiNet) bespoke webpage that writes to a XML file that is used by a subflow script within the main customer script in order to control when an Alert message is enabled.  However; for what you require a similar thing could be achieved using a basic prompt recorder script with the prompt upload configured to upload into the customer prompt directory and then enabling and disabling this using the script variable parameter setting.  Steve

nowcommsupport
Level 1
Level 1

By the sound of it, you're after a phone-based system that will enable the caller to record and upload new prompts, without any sort of web-based interaction. The simplest way I've found to do this, is to choose a numeric naming convention for prompts, so that they can be easily referenced using the phone's keypad. Then, when a prompt needs to be re-recorded, a supervisor (for example) can call the recording application and key-in the ID of the prompt that they wish to re-record. This is fairly straightforward and overwrites the existing prompt immediately, but requires up-to-date documentation for the end-user.

Another way of doing this relies on using XML files to share settings between scripts. You can create a 'control' script, which allows callers to choose a mode of operation for the contact centre and stores this in an XML file. This is read-in by the 'main' script, which changes its behaviour accordingly.

In this case, you could design a 'control' script that gave a caller a choice of recording (and activating) a temporary message. The script could then change one of the XML parameters, so that the 'main' script played the temporary recording before callers were placed in the queue. When the message was no longer needed, it could easily be de-activated again using the same 'control' script.

Bear in mind that a prompt can be empty, but still played by the script. The caller will hear silence, but the Play Prompt will still be executed. If you wanted, you could use this to create a temporary prompt that played queuing messages when needed and then be overwritten when not.