Updated - June 25th, 2005
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.
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.
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.
THIS CHANGE WAS REVERSED IN A LATER UPDATE DO TO REQUESTS FROM
- 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
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.
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
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
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
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
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
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
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!
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
- 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".)
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
- 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)
Additional dialer changes
can be expected in future releases.
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)
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.
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
- 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.