I had a lengthy chat session online with Ab in India early this morning. He reports the dialer is ready to use. This is true, however only an experienced programmer (like Jeff Wilson) can use it at this stage. I can’t.
Jeff Wilson must write a separate customized program for each calling campaign we wish to conduct. Once the program is written, it must be uploaded to the dialer and tested with a “test” calling list (a CSV file filled with call parameters and phone numbers) before the actual “live” campaign is started. After the test is successfully completed, and all non-working elements are debugged (this is normal when testing a program, even one as simple as a PHP calling script), we will be able to run a “live” dialing campaign. For now, this lengthy and confusing process is what must be done for each and every dialing campaign.
In layman’s terms, this means that if we wish to acquire GroupCastTM and/or GroupCallerTM Clients other than ourselves, we must manually set up and configure each and every group call they wish to send. This is, of course, too labor intensive to be profitable unless the Client is going to make hundreds of thousands or millions of calls in a mass advertising campaign. Until we can create a reasonably simple calling campaign user interface for me or other users, we’ll have to restrict Client acquisition for Group or Mass Distribution of calls to only ourselves and possibly some very large Clients (like mass robo-calls for political campaigns).
At this stage, there is no neat-and-tidy looking Graphical User Interface that lets a non-programmer run the dialer . That will come later as we progress through Phase I of our marketing strategy and gain sufficient cash flow to re-hire our previous programmers and add new programmers, web designers, engineers and analysts to the staff. As you know, we’ll begin adding these personnel AFTER we have reached the goal of 400 paid & paying AMG members. Only an appropriate programming, design and engineering staff will be able to make the GroupCallerTM system a tool that can be used by our Clients without programmer assistance. However, we “WILL” be able to use it for our own purpose of running our outbound dialing campaign, which is designed to locate prospects for AMG memberships. As of this posting, I’m very optimistic that we’ll finally be able to start our own calling campaign no later than Friday and possibly as soon as tomorrow.
If Jeff has enough time this morning to create a call script, we should be able to begin making a few test calls using the first call flow we created last week. You can see that call flow chart on my March 22 blog post. Those of you on our beta test team will likely get a phone call from me late today or sometime tomorrow … or if I don’t have time to call everyone personally, I may just have to send an email. At any rate, whether I call you or not, don’t be surprised if you get some calls from the system late today or this evening.
The good news in all this is we now have a VERY powerful, fully functional voice broadcast system capable of making outbound calls on as many concurrent channels as we designate, and running as many different campaigns as we designate … all at the same time. Naturally, we cannot really make “unlimited” calls for “unlimited” Clients at this point. That’s because we are limited by five things:
- The number of servers in use (about 400 concurrent calls can be made on a single computer server), and
- The bandwidth available for outbound calls (i.e. the UPLOAD bandwidth).
- Time.
- Personnel.
- User interface allowing non-programmers (whether internal staff or Clients) to use it.
These limitations are relatively simple to overcome, but will take a lot of work to accomplish. We’ll need sufficient funds available to buy more equipment and pay for more bandwidth. That money will come from the sales we’re making as the result of running our own dialing campaign.
Our current bandwidth will allow us to make 20 to 30 concurrent calls. An easy upgrade to the bandwidth will increase that to hundreds of concurrent outbound calls without the need to invest in more equipment. We don’t wish to run more than about 10 to 20 concurrent lines initially because we need to do substantial testing and monitoring of these calls during the first few weeks to ensure that the system is stable, that no bugs are present, and that our system is capable of compliance with various laws that regulate the actual operation of the software and equipment (as an example, the law requires that we must allow a phone to ring a minimum of 4 times or 15 seconds before hanging up, it also requires that the called party be able to press a key on their phone to be automatically added to our internal Do Not Call list at any time during the call and then have the call terminated…and there are even more regulations, but this will give you an idea of what I’m referring to). We can’t begin “LIVE” calls until we can verify that these legal requirements and all other aspects of the program work flawlessly.
Whew!
Sorry for the long article, but this is a very, very big step forward. Now, I’m depending on Jeff to prepare us for the first test calls.
Comments