© Quantrax Corporation, Inc.
 Updated - June 25th, 2005
As announced, this will be the last major update to Intelec, prior to the availability of Version 8.0. This version does not contain any major database changed compared to Release 7.2 other than for file changes required for I-Tel. The installation instructions for this update are within the installation instructions for Release 7.2. This documentation was created to separate some of the recent changes from Release 7.2.

NOTE - The final version of Version 7.4 was created on June 25th, 2005. If you received your update prior to that, some of the features described here may not be in your version. We will be sending everyone the final version starting July 1st.

The database changes that are present were needed as a part of the support for I-Tel, our integrate dialer platform. In the coming weeks, users who were on Release 7.1 will receive code to take them to Release 7.4.
These users should review the Release 7.2 documentation as well as this document. For those of you who are on Version 7.2, you will also receive code to update you to Release 7.4. In this case, this documentation is all you will need.

The following changes have been made. Please read the documentation carefully before installing the new software. Some of the links and screens samples are best viewed at a resolution of 1024 X 768 or higher.

Click here for a PDF version of this document.


  • Changes to inquiry - In this update you will find several changes that apply to security. This is becoming a major issue based on client requirements and the potential for identity theft.

    • Presently the inquiry screen (search) will display complete social security numbers. We will now only display the last 4 numbers (in format XXX-XX-8989) and ONLY show the accounts which exactly match the selected data. (We will not allow a user to "fish" for data" Once a user selects an account and the details are displayed, we will show the complete social security number. At this time, if the user exits an account without doing any work you can have the system add the account view noted. In the case of an abnormal exit such as by closing the window, a note will be added by the system.

    • On the first detail screen, social security number will show leading zeros. If no social security number exists, 000-00-0000 will be displayed.

    • The X-Reference fields will use the same security as the debtor name field with reference to update authority. (Based on system security) Several users add sensitive information to the X-Reference fields and this was the reason for this change.


    • What if you want to stop users from accessing specific accounts based on some valid reason? e.g. This is a dispute and you do not want any user other than a a few managers or a group of users accessing those accounts? You can accomplish this from the description code level. On the Description Codes System Control file, there is a new field called "Special warning message". This is up to 4 lines of a message, similar to the pop-up windows at the client level. If you enter ANYTHING in this field you are telling the system that an account with this description code will require special authority before it can be accessed. That authority is given to the user through a new field in System Security called "Allow access - Special Desc.Code". A "Y" in this field means the user WILL BE ABLE TO access accounts with the special description codes. If the use has no special authority, and tries to access an account with a special description code, the "Message" set up on the description code will be displayed and the user will NOT be able to call up the account detail screen for that account. Remember that in addition to the account search, a user could access accounts through the linked accounts summary (F5), additional linked accounts (F6 from F5) or the F21 (primary accounts from details) options. All of these options will check if the user has the authority to access the account selected, based on the new description code logic. Note that this new description code logic does NOT apply to accounts IN A USER'S QUEUE. If the account is in a specific user's queue, then we assume they should be able to access it when they go into the account processing options!

  • Account detail screen - The account detail screen has always showed the promise (or follow-up date) and promise amount. What if there is a payment arrangement (P/A)? In this case, a collector should NOT date the account or enter a promise amount. But in this case, you do not know what the amount promised is from the account detail screen! We will look at payment arrangements (F9 screen) and display the total due and due date from the P/A in the account detail screen's promise amount and date fields (downpayments are not considered). That P/A information will be replaced by the follow-up date and any promise amount FROM THE ACCOUNT (there should not be a promise amount for a P/A, unless there is a broken promise) when the user does ANYTHING on the detail screen (ENTER key, any function key etc.). We basically display the payment arrangement information for a very brief period.


  • Account Processing queue creation - Presently dates follow-up's take priority over new business. If an account has a follow-up date (but not a promise amount), and if the follow-up date is reached and there are NO attempts OR contacts on the account, the logical reason for this would be that the date was used to temporarily hold the account from a collector. If the account qualifies as new business it will be placed in new business as opposed to dated follow-up's.

  • Restricting access to accounts based on client codes

    We wanted to provide a comprehensive solution for restricting and allowing access by client for Intelec users. With such a requirement it is assumed that you will only link by client or client group!

    Overview of requirements -

    The needs are more complex that they seem at first.

    1. Some users must be allowed to access ALL clients.
    2. Some users should be allowed to access only SPECIFIC clients.
    3. Some users will need to access all BUT a few specific clients.

    How do we accomplish this without also creating complex setup rules? e.g. Suppose 100 specific users were to have access to one special client. Those users also needed access to ALL other clients. If there were another 500 users who needed access to all BUT 4 clients, how we set all this up? Having to set up options for EVERY user is simply NOT viable!

    And the solution?

    In the client security for 7.2 (from within System Security), you could enter clients or groups and then a Y to allow and N to not allow access.

    There are some new features.

    a) Option "A" will mean allow access to all clients. Nothing has to be set up in the client codes area for this option.

    b) You can set up rules for THE COMPANY by setting up a User ID *DEFAULT. We see this being used in a case where, as an example, you had 7 special clients who could only be accessed by say 20 users. You would set up *DEFAULT to NOT allow access to the 7 special clients. At this point NO ONE can access the special clients.

    To access the special clients you could set up the 20 special users with either option A - if they could access the special clients AND all other clients OR, if they only worked the special clients, set them up with option Y and define the 7 clients in the System Control file.

    Based on the above, only about 20 entries are needed for 500 collectors!

    c) If *DEFAULT is to not display a client, and user is set up to display the client, user rule takes priority - User can access the client's accounts.

    d) If *DEFAULT says display a client ... and user is set up to NOT display the client, the user will not be able to see the client's accounts.

    e) What if... 200 users should not see client A, 20 users should see client A only, and 200 other users can see all clients?

    In this case, you could set up *DEFAULT to not show client A (company rule). Set up the 20 users to only access client A only (set up a rule for each client). The other 200 users - It would be a lot of work to set them all up to access all clients! We have a special User ID *ALL that you can set up. If a specific user has no rules, we will look up the rules for *ALL to get any rules for that user (a type of default)

    The system first looks at default rules (*DEFAULT). Individual user rules override *DEFUALT and if there is no user rule, system will use rules from *ALL, which will override *DEFAULT 's rules.

    We feel that the above features will allow you to be very flexible without having to set up hundreds of users on different profiles!

  • Smart Codes

    • Presently, if you apply a Smart Code, through the note line (*xxx* format), that Smart Code can NOT be duplicated on linked accounts (even if it says "duplicate on links"). We treated that as a simple operation that only applied the Smart Code to a single account. There are reasons that you may want to duplicate the Smart Code applied through the notes line. This feature would allow you to check the linked accounts and apply a Smart Code on ALL of the linked accounts based on the conditions on a SINGLE account! The duplication is accomplished by entering "DUP" immediately after the 2nd asterisk. E.g. *501*DUP will apply Smart Code 501 and duplicate it on linked accounts based on the Smart Code rules. Any text AFTER the DUP will be added as a note on the account.

    • We have always asked ourselves the question "When should an account be removed from a work q-ueue"? There are many answers. The logical one is "When you have a contact". We have made a change that will mark the account as "worked" from the account processing angle, if the the smart code updates the date last worked (i.e. you do not have the smart code set up as "Do not update date last worked".)

  • Productivity reports - A while back we disabled a date range option from within some of the productivity reports. (Account Processing Review from the Management Menu, then option 1, Account Processing Review by User.) We had removed the date range option for the "Month" option. There were problems with that option. We have now resolved those problems and the option has been added to the screen.

  • Display accounts for Audit - We have enhanced this option (Option 6 from the Smart Code / User Audit option on the Management Menu).

    • For attempts and contacts, you can now enter Y, N or a number. To specify more than 9, enter 0 (zero).
    • To select accounts which have never been worked (no date last worked) enter 999999 to 999999 in the date range for last worked.
    • You can now enter a client range or group range! Leave the ending client or group (to option) blank to select a single client.
    • You can select a client consolidation code (option on client master)
    • You can specify a reporting group code (option on the collector master)


We have made several changes to I-Tel, our integrated dialer. Many of them have focussed on making the system more stable by not allowing users to do things they should not do or making a logical and practical decision when a user tries to do something they should not (e.g. If a person is on a call in preview mode and they try to go to the next account, the system will disconnect the current call!) This is logical. This will add greater control. Please understand that complete flexibility is not easy to provide with a complex system such as an "integrated dialer". We have had to make some choices for technical reasons.

Some of the key changes we have made are as follows -
  • We offer multi-dialer support - You can have multiple dialers working off a single iSeries database (e.g. at different physical locations)
  • Introduction of DNIS text. This allows you to associate a number the debtor called with some text that you define (e.g. Debtor called Johnson Hospital) and this information can be displayed to the inbound agent. In addition, you can display information about the debtor, if we able to match the calling from number to a unique account.
  • Introduction of playback message support - This allows you to play a message during a conversation. (Using Pxx - e.g. P02 in Smart Code field). That will play a specific message - The agent will hear the message and can talk to the debtor after the message is complete. You can stop the message playback by entering STP in the smart code field. You can use Xxx e,g, X01 to disconnect the agent from the call and play a message. These messages have to be recorded as WAV files - Different messages are then associated with a specific WAV file.

  • We enhanced the configuration of NNE's (non nailed-up extensions)
  • For efficient use of resources and the best system performance we automatically place predictive calling lists in "mini-queues". This stops the system from accessing the very large Intelec queue file to fetch records during a predictive campaign. That takes a great deal of system resource. As you can understand, this code is very complex, since we have to manage the same information in multiple places. This will save some of you expensive system expansion costs as you grow your dialing capacity.
  • We added support to display the status of an agent and hunt group information. We have menu options to show what campaign an agent is in and to show what hunt groups are active and what agents are in those hunt groups.

  • We introduced hunt group support for NNE's.
  • We had some problems with calling multiple numbers on a single campaign (e.g. home and work numbers). This support should now be functioning as expected.
  • We have added powerful reporting options to analyze campaigns and show you exactly what each agent did, broken down by the type of contact made (based on Smart Code) and the monies promised through different methods (promises, payment arrangements, direct checks etc.) This is unique to the industry. Other systems provide dialer statistics and sometimes, separate productivity results. Combined reports are simply not available!

  • Do not call logic has been expanded to allow you to set up a complete area code, or an area code plus the next 3 numbers, in addition to specifying complete 10-digit numbers. Be careful if you use these options. We will mark the queues based on these rules. Predictive campaigns will not have numbers to dial if you have incorrectly set up a table and the phone numbers are removed from the queues.
Additional dialer changes can be expected in future releases.

  © Quantrax Corporation, Inc.
  June 2005