Application Design

• You probably know about the "Run Test" button on Transaction pages. It's a quick and easy way to send some test parameters to your server, and see how your script responds. But if your script relies on information that was passed on previous calls, or the test data is hard to replicate, it is sometimes better to test your script with a real phone call. Angel.com can send you an email with the real values spoken by your callers, and the actual response from your system.
  
• To access this functionality, click on the "Advanced Options" button of a Transaction Page. At the bottom, it will display:
  
  
• ... just specify your email. From the Mail Logs drop-down, choose Always if you'd like to receive an email every time this page is visited. This is the setting I start my Transaction Pages with. Once I've figured out the major bugs, I change this setting to On Error Only. This helps me monitor the Voice Site, in case my web server goes down, or there's a hidden problem with my script that I didn't discover.

Asking the same question in different ways:

• Let's say you need to collect an employee ID from your callers, to then check that it exists and give them access to the rest of your Voice Site. If the authentication fails, you could just play "This employee ID is invalid" on the response of the Transaction page that does the authentication, and then take them to the page that asks for the employee ID. Although this approach works, it would be more natural to ask the question in a slightly different way the second time (e.g: "Hmmm.. that number doesn't match my records. Let's try again. What was that employee number?").
• A simple way to achieve this with Angel is to use 2 Question Pages to do the asking, and select them as parameters in the following Transaction Page, but using the same parameter name:
  
  
• Angel will send all the values in an array under one key. The last value of the array will be the most recent one. With this approach, the script that authenticates, doesn't need to know how the capture of the employee ID was achieved, just validate it. If you need to prevent more than 'x' authentications, the size of the array will act as a counter that you can use to drive the next interaction.

Securing your application with SSL.

• If your application deals with sensitive personal information, I recommend the use of SSL to transmit parameters and responses between Angel.com and your server. This will ensure that nobody can snoop on the communication, and will help maintain the security of the overall application.
  
• Using SSL is easy. Here are the steps to follow:
  
  • Buy an SSL certificate from a reputable source. (Angel works well with Verisign, Thawte, and others.) The best working certificates are issued by Root Certificate Authorities. You can see these in Internet Explorer under: Tools > Internet Options > Content > Certificates > Trusted Root Certificates.
    
  • Install the certificate on your web server. Good instructions are published by Verisign here -- http://www.verisign.com/support/site/secure/install.html
    
  • Change your Transaction pages to use https. This will involve changing the url on each page from http://your.server/... to https://your.server/... or https://your.server:443/... One thing to take into consideration, if you are using session variables is that most servers will generate 2 different sessions when receiving secure and insecure requests from the same client, so it's wise to change all your Transaction Pages in one go.