<div class="gmail_quote">On Tue, Aug 25, 2009 at 2:52 PM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
</div>With enough spiritual commitment, anything can be done; you certainly<br>
*can* do it this way. You can write a fairly sophisticated dialer in<br>
Bash, too.<br>
<br>
The issue is whether it is methodologically correct and qualitatively<br>
appropriate. It is much easier to schedule calls and manage outcomes<br>
dynamically - such as highly granular agent stats informed by<br>
up-to-the-minute heuristics, or aggressive overdial ratio control - with<br>
real-time monitoring of both call initiation and call results via AMI.<br>
<br>
It's a question of ROI on your time. You can do it however you want,<br>
especially if you're really motivated to avoid a particular type of<br>
development chore.</blockquote><div><br>
</div></div>What you are saying makes sense, but I haven't used AMI for anything yet, so I cannot comment on how easy/reliable/stable it is do work with in terms of developing an autodialer, but I just did not agree when you said it was definitely the way to go, because there is not one way to go. The one I did, using call files to dial was pretty reliable, and I you are able to distribute the calls different servers using the interface.<br>