Version 2.1 - Updated September 10th, 2004

Updates - September 10th. Roadmap for conversion to new release was added.

Version 8.0 is a challenging update to Intelec that will contain some complex database changes as well as significant changes in functionality. The changes are extensive. While we had initially considered omitting any significant database changes, we have realized that this will only increase the work we have to do in the very near future. Therefore we will do some of the major database changes in this update. Some of the changes are very complex and will not be available in the initial version of the update. The deployment of the new version will be in multiple phases. Quantrax has recently made a decision to deliver enhancements on a quarterly basis. Our target delivering the initial version of Version 8.0 is September 2004 (3Q 2004). In the first phase we will deliver all the database changes and several functional changes. Additional function changes will be delivered in the quarterly updates. If you have not already done so, please take a few minutes to review Quantrax's dialer platform. This product is now integrated with Intelec (Version 7.2).

Within the last 12 months, we identified and defined several areas of Intelec that could be enhanced. Some changes have already been incorporated in Version 7.2 while others will become a part of Version 8.0. We have also indicated the planned delivery date for each feature. Please send any comments to ranjan@quantrax.com.

Account management

• We will edit area codes at the time new accounts are posted. We will be able to fill in area codes for accounts that do not have them. You will be required to purchase a file that has area codes and time zones and keep the data updated through a subscription service. We will use the same file to indicate and manage the times when accounts can be called by your collectors. There will be options to periodically update area codes when changes take place in specific areas or states. (3Q 2004)
  
  
• In keeping with some of the HIPAA guidelines, we will provide support for additional addresses for a guarantor (mailing, confidential etc.) (3Q 2004)
  
  
• On duplication of information, we will provide options to stop information from non-medical accounts being duplicated on medical accounts and vicé versa. (3Q 2004)
  
  
• We will add a field called “Change of address or mail return date” to the account master file. (3Q 2004)
  
  
• Presently we have a field for one external score. This will be expanded to allow you to retain up to 3 external scores. (Done in 7.2)
  
  
• When an account is displayed, we will warn the user if purged accounts exist for the same debtor (based on Social Security number) (3Q 2004)
  
  
• We will allow the duplication of POE and Medical Insurance information on linked accounts. We will also add SS# and date of birth to the duplication options. (3Q 2004)
  
  
• We will provide significantly enhanced phone number management tools. We will track bad numbers and warn users when a new number they try to add was previously removed from the account. We will also allow many potential home phone numbers to be stored in a phone number file, and have those numbers retrieved into the home number field when a home number is removed. We will create a database of phone numbers that will contain (at the account level), a source of the number, type of number, date obtained, date and time last used and date number was confirmed bad. (4Q 2004)
  
  
• We will create a list of “do not call” home and work numbers and display that information in some format when accounts are presented a user. (Done in 7.2)
  
  
• If a description code can not be added by a user (based on system controls) the duplication logic should not duplicate those description codes. (3Q 2004)
  
  
• We will investigate the ability to display information about an existing HIPAA agreement with the client. (4Q 2004)
  
  
• A purge by client has been requested by our users. This was primarily needed when a company ceases to collect for that client. The concern is the need to back up and store purged information. We have a simple solution – We will add an option to stop any user from accessing accounts for a specific client. The flag will be available at the client level. The information could be displayed on the inquiry search screen, but the account can not be accessed in the detailed format. You can obviously use a multiple Smart Code assignment to close the accounts for that client – they can then be purged when the option is next selected run. We can also modify the purge to look at this flag and purge accounts for the client regardless of the “waiting period” for the specific close codes. (3Q 2004)
  
  
• We will increase the interest balance to support numbers up to $9,999,999.99. (3Q 2004)
  
  
• Some of you have asked for more secondary balance types! This is a major change! The reason you need this is because some clients have balance type (descriptions) that are different or unique to that client. We will allow you to define different descriptions for each balance type at the client level. The options such as reportable, commission take etc. will be only maintained at the company level. You should have no problem working with this. We will provide support for a different distribution order for the balance types at the client level (this is already available). (3Q 2004)
  
  
• We will provide a field called “Original creditor” and “original account number” at the account level. This will be useful for debt-buyers or companies that receive accounts from billing services. This information will be available for addition through electronic loads only. (3Q 2004)
  
  
• We will be expanding some of the fields in the insurance information screen. (F16) (3Q 2004)
  
  
• We have had several requests for increasing the number of characters in the close code. Most of our users will agree that there are relatively few “primary” reasons for closing an account (e.g. refused to pay, dispute, write off etc.) Within the primary reason, there could be several sub-classifications (e.g. for a write of – charity, VIP etc.). It is for this purpose that the additional coding is usually required. While there are advantages to having a 2-character close code, we feel that retaining the present close code and adding a new 2-character code to sub-define the close code will be more beneficial to our users. We will make this accessible through Smart Codes and the account details. The new field which we will probably call a “Close sub-code” can be set up so it can only be associated with certain close codes. E.g. You could disallow a “Charity” sub-code on a dispute. (3Q 2004)
  
  
• We will change the collector codes (Owner, worker and split) to 4-character fields. This is a very significant internal change. (3Q 2004)
  
  
• We will add a cell-phone number to the account file. (3Q 2004)
  
  
• We will allow you to stop automatic linking to accounts based on the close code of the old account. (3Q 2004)
  
  
• We will provide a method of applying a Smart Code at the time of posting an account electronically. (3Q 2004)
  
  
• We will allow you to translate letters based on the existence of a description code. (3Q 2004)
  
  
• There is a feature in Intelec that allows certain users to only "view" System Control information. We will expand this feature to include QCat codes, ACat codes, Status codes and State options. (3Q 2004)
  
  
• We will create the work maps at the end of nightly processing as opposed to after the queues are created. Reason - During nightly processing, after the queues are created, you may consolidate queues (New dialer options) or remove accounts from the queues. (3Q 2004)
  
  
• We will be a adding several fields that will allow us to expand the area of compliance, which is likely to be a key issue in the coming years. (4Q 2004) Some of the functionality will be added in subsequent releases.
  
  
  • We will add a last date of contact (any contact as defined by a Smart Code). We will also add date and time of last right party contact (RPC). There will be a field on the Smart Codes to define a RPC.
  • We will add fields to the expanded logic to make decisions based on the above dates. (E.g. days since last RPC)
  • We will add a date of last attempt (based on the Smart Code being an attempt)
  • We will allow an account to be marked as a "complaint", based on a Smart Code. Any time such an account is accessed, the user will be warned. The complaint will be removed through a Smart Code.
  • At the state level, we will add an options "Do not call within X days of right party contact", "Do not call within X days of right party contact" and "Do not call within X days of attempt". This will stop accounts from being selected for account processing for specific periods since a prior event.
  • At the state level, we will indicate whether a message left should be considered a contact for marking the account for compliance-related work. We will also have the option at the Smart Code level to define a "message left". If the options are specified, the account will be updated as a "contact" for compliance, as opposed to a RPC.
  • We will add the Smart Code expanded logic to identify a US or Canadian account, based on the state or province. We will also add a country field to the account file for future use.
  • At the state level, we will need the option to stop calls to work numbers.
  • At the state level, we will have an option to indicate the maximum number of times we can call a person per day. This will be linked with the dialer interfaces and predictive dialing options.
  • We will allow the user to set up an option "frequency of calls until first RPC is made" based on the state. If this is set up, the account will be managed appropriately for the queue creation options.
  • At the state level, we will add a option "Range of dates to call after placement, until RPC". If you set up 5 to 30, we would not place the account in a queue prior to 5 days or after 30 days from placement.
  • We will set up a field to indicate if IVR is allowed or not, at the state level.
  • At the state level, we will allow you to define "Days when accounts should not be worked". This will allow you to stop calls based on special state holidays, if this were necessary.
  • We will allow complaint information to be stored at the account level. Special authority will be required to access complaint information.

System changes

• Presently, the first 4 characters of a User ID for Intelec must be unique. We will remove this restriction and allow you to create any user with up to 8 characters in the User ID field. (The AS/400 has a 10-character User ID field, but we will not change our system at this time) (3Q 2004)
  
  
• The Nightly Processing allows you to perform a power down operation. We will allow you to call a program prior to this operation being performed. (4Q 2004)

Working accounts

• Presently, we track owner and split code changes in the notes. We will track worker code changes too. (Done in 7.2)
  
  
• For an on-line client, we will make the last letter information only reflect information from the displayed account and not all of the links. (Done in 7.2)
  
  
• When direct check information is deleted, we will retain the checking account information. (Done in 7.2)
  
  
• We will make the F7 key from the F10 screen take you to the first detail screen, as opposed to taking you out of the account. (Done in 7.2)
  
  
• We will provide a method of display different Social Security numbers on a linked group of accounts. (4Q 2004)
  
  
• On the linked accounts screen (F5) we will identify bad addresses. (3Q 2004)
  
  
• We will allow you to check that the first payment for a nonlinear arrangement is not too far in the future (same logic as for standard Payment Arrangements) (4Q 2004)
  
  
• We will display the linked balance on the direct checks screen. (3Q 2004)
  
  
• We will create a linked account analysis. This will display information based on careful analysis of the linked accounts. Information will include -
  
  
  • Dates of first and last placement
  • Total placed, total payments, first and last payment dates
  • Dates of first and last contact
  • NSF history, including last NSF and date.
  • How many accounts have been credit reported?
  • Have we obtained direct checks?
  • Have we set up a payment arrangement? What was first and last start date?
  • There will be information that will displayed to management, that will not be available to a collector. This will include recovery rate for the client, recovery rate for that batch of placements,
    
    
• There is an “Other Information” screen that can be accessed from the TAB-Q option. We will allow this screen to be duplicated on linked accounts. (4Q 2004)
  
  
• We will expand the information on the extra phones window to include details such as a description (e.g. neighbor), date obtained, date last attempted, date of last contact, flag to indicate number is bad, user who created or updated the data,
  
  
• In the last release, we started to track the last 5 accounts displayed by a user. This allowed you to easily go back to an account that was recently worked. Presently, you have to key in a case number for the account. In addition to entering a case number, we will allow you to access a prior account by keying in a code (e.g. L3 for the 3^rd account on the list) - Done in 7.2
  
  
• For direct checks, we will give you a method of automatically extending the "arrangement" if all the checks have been presented in the case where several postdated transactions were set up. (Done in 7.2)
  
  
• The on-line client module is a standard part of Intelec. We will expand the logic to allow the feature to be used with a forwarded agency. The agency will be able to only see accounts that are with that specific agency (or attorney) based on the forwarded agency codes defined in the "client code fields" of the System Control file for on-line clients. (4Q 2004)
  
  
  

Payment-related options

• Add a note at the time of payment entry, indicating that a payment is being processed. Indicate amount and type on the primary account. Allow a Smart Code to be applied at the time of payment entry (automated option). (3Q 2004)
  
  
• Allow payments to be taken in currency other than system currency. Amount will be converted to system’s currency at time of payment entry, based on exchange rate tables. (2005)
  
  
• We will keep the date and time of payment posting on the payment history file. (3Q 2004)
  
  
• We will store split commission percentage at the payment history file level. (3Q 2004)
  
  
• Payment posting will take place in batch mode. (3Q 2004)
  
  
• Store a list of credit cards that we should not allow to be used. (4Q 2004)
  
  
• There will be a method of creating an unlimited number of open transaction batches per user! (Done in 7.2)
  
  
• The payment history file will be expanded to hold a bank processing date, more information on returned checks (date and reason). (3Q 2004)
  
  
• Based on the client code, we will give you the option to automatically omit the original payment and the reversal from the statement, when NSF’s are posted (provided original transaction has not been reported). We will automatically copy this field to the other client codes when the duplication option is used for group numbers. (4Q 2004)
  
  
• We will validate credit card numbers entered – A user will not be able to enter an invalid card number (There are valid card numbers and we are also able to check the type of card e.g. Visa, based on the number) - Done in 7.2
  
  
• We will add intelligence to adjustment codes. You will be able to make important decisions based on the adjustment code used. (Done in 7.2)
  
  
• On payment entry, we will allow an incorrect transaction to be edited, as opposed to the need to delete and reenter the transaction. (4Q 2004)
                                                          

Real-time Inquiries

Quantrax is committed to expanding the management and user inquiry options that will be available through Intelec. In general, our designs will use the assumption that only recent information is of real value. We would therefore use information for the past 30 days as being the most relevant. There are reports that are currently produced daily  that could potentially be replaced by on-line inquiries (e.g. Payments by collector). The option to produce these reports interactively will be a great help. As always, it will be desirable to stop specific users from accessing these reports. 

• We will allow a user to display an updated workmap which will show the accounts worked and the number to be worked for each QCat Code. (Done in 7.2)
  
  
• At the user or management level, we will allow a payment detail list to be displayed for a specific date, going back up to 30 days. (Done in 7.2)
  
  
• For management, we will be able to display productivity summaries by user in real time. (Done in 7.2)
  
  
• Time management reports will also be available. (Done in 7.2)
  
  
• There will be a postdated check inquiry option. This will incorporate checks mailed as well as direct checks pending. (Done in 7.2)
  
  
• One of the most exciting features we have developed is an on-line account audit. The user has many options (selection criteria) to target a specific group of accounts. The system will identify those accounts and display a list on the screen. The list can be printed or a Smart Code applied to all of the accounts on the list. This option has already been tested at a few companies and the reviews have been amazing! (Done in 7.2)
  
  

Collector Management

• Presently, time management is by processing type. We will expand it to include specific QCat Codes. (3Q 2004 or 4Q 2004)
  
  
• We will give you a method of maintaining a completely independent Smart Code Series at the “Worker Code” level for all account with a specific worker. This will give you a method of “reviewing and managing” the accounts that are with a specific worker! E.g. You could look at the accounts every 15 days, and check if an account had not been worked for 15 days! The possibilities are many and interesting! (Done in 7.2)
  
  
• Presently, there is an option to monitor a collector and look at exactly what screens they are working on. This monitoring feature uses an IBM command that sends a message to the user being "monitored". The option only displays the previous (not current) screen that was presented to the user. We will add an option to the audit feature "Display accounts worked" to allow you to display the last account that was worked by a user. If the account is presently being worked by the user, the time the account was first displayed and the time spent on the account will also be displayed. (Done in 7.2)
  
  
  

Smart Codes

• We will provide a Smart Code Map. This will list each Smart Code, indicating exactly where in the system that code is used. E.g. in other Smart Codes, contact series, smart code series etc. (4Q 2004)
  
  
• Expanded thinking will be enhanced to include more complex fields such as date of last contact – information that may have to be computed. In addition, information such as insurance company will be added to the list of fields processed. We will also add a wildcard feature for certain options (e.g. Select account if the POE begins with IBM, or zip code begins with 221) - Done in 7.2
  
  
• For certain fields, allow several “OR” conditions to be specified on a single line (e.g. QCat is 265 or 255 or 656) - Done in 7.2
  
  
• We will review the possibility of resuming a Smart Code Series at the point it was stopped. (3Q or 4Q 2004)
  
  
• We will allow decision-making based on the age of the newest account. (Done in 7.2)
  
  
• We will provide the ability to delete home and/or work phone numbers through a Smart Code. (Done in 7.2)
  
  
• We will provide a method for the system to apply a Smart Code when a P/D checks, direct checks or payment arrangements are set up. (3Q 2004)
  
  
• On the Smart Codes System Control file update, provide direct access to the list of fee codes, contact series etc. This will allow a user to find a code quickly or obtain the description of a specific code. (4Q 2004)
  
  
• On the file that we use to apply Smart Codes (SCTRAC) we will add a Smart Code override field. This will allow us to use a specific Smart Code through automated processes, greatly reducing the need for new codes! (Some of you are running out of Smart Codes, and we do not plan to expand the field to 4 characters) - 3Q 2004
  
  
• We will add a search by override code for the Smart Codes System Control file. (4Q 2004)
  
  
• Most of you have probably had an instance where a certain Smart Code needed to be applied to all of a specific client’s accounts on a specific date, not before, not after, but on a specific date! The only option was to remember this and make sure you ran a multiple Smart Code assignment on that date. We will give you a method of setting up the system in advance of the required date, to apply a Smart Code, at the beginning of Nightly Processing, on the date that the Smart Code is required! (Done in 7.2)
  
  
• Presently, the standard note on a smart code is one line of notes. We will allow you to add a note with more text (up to 6 lines). - 4Q 2004
  
  
• We will allow a Smart Code to call a user-defined program. We will pass the parameters company code, case number and Smart Code and call a program that is defined within the Smart Code. (4Q 2004)

Client information

• We will have fields to store billing company information at the client level. Some of you receive accounts for a client through a billing company, and will find this information useful. (4Q 2004)
  
  
• For the on-line client module, we will only display the options the user has access to, when the on-line client menu is displayed. (3Q 2004)
  
  
• Presently, there is a screen with several user-defined fields. We will allow you to define the “Titles” for each of those fields at the client level. (Done in 7.2)
  
  
• We will add a SIC code at the client level. (3Q 2004)
  
  
• Presently, to-date numbers (total for all activity for all years) is not retained at the client level. We will add those numbers to the client master. (4Q 2004)
  
  
• Presently, we will create a separate transaction for all overpayments (Type 03 or 13 payment code). We will give you a code at the client level to take the entire payment as a commissionable amount, without splitting the transaction into separate parts. (4Q 2004)

Reports

• The Placement History Report will be modified to print the active number and count from the total of the open accounts on the system. As an example - Presently, some transactions such as balance adjustments or overpayment reversals that are incorrectly coded will affect the active column. The active column will not match the active column on a status report that shows only open accounts! This will be changed so that the active column on the placement history will match the actives on a status report. As a result of this change, the total of “Placements less adjustments, less payments, less closes less withdrawn” may not exactly match the active column! We will add any differences to the balance adjustments column. (4Q 2004)
  
  
• We will provide a Status Report and Close Report for forwarded accounts, allowing the selection of a forwarded agent. (4Q 2004)
  
  
• On the Detailed collector audit, we will allow multiple collectors to be selected. (3Q 2004)
  
  
  

Web-based features

During our user meeting we presented several web-based features that could be of practical use to our clients. Unfortunately, these would not come under the area of base-system changes and would be separate, billable modules. There was a great deal of interest and Quantrax is proceeding with the development of some interesting, web-based features.

We have identified the following as application areas within our web-based modules. We expect to have these features code-ready by 4Q 2004.

• Allowing a debtor to access the system through a browser. After an authentication process, the debtor would be able to
  
  
• Check their balance
• Obtain basic information such as mailing address for the office
• Enter credit card information and a payment amount resulting in the Intelec information being updated for required action the following day. In the initial phases, we will only use this feature to update the Intelec data, not to process the credit card information with on-line verification etc.
• Specify checking account information that could be used to print a direct check the next day.
  

• Whenever a debtor accesses their account, the details would be documented on the account. You would have the option to have the system apply a Smart Code!
  
  
• There would be a method of the debtor “entering a message” that could be accessed by a collector.
  

• We want to allow our users to have several different options for delivering reports to their key clients. Even with the internet, it may not be practical to allow web-access to a 1000-page report (e.g. a Status report). However, it will be practical to allow a client to view their placement history reports on-line. In the case of larger reports, creating a CD containing a formatted report or an EXCEL-format file could be additional options. (All options will only be available in 2005)

We presented some of these concepts and warned our users that there would be a cost associated with these features. In addition to the basic software that has been described above, we have the challenge of incorporating the functionality into your website. This is also a significant challenge. Quantrax is considering the possibility of offering you this consulting – This will mean that we can do most of the technical work necessary to incorporate any web-based features into your system and workflow.

Changes that affect medical collections

We will be making several fields to the database, that will in turn allow us to add new functionality. Following is the final list of the ideas that we received from the "Healthcare user's group". The following items were presented by the user group, in order of priority.

1. Better Database manipulation capabilities.
2. Easier methods of importing and exporting data into and out of the system.
3. Insurance sequence # - new field to track priority of this insurance plan (primary, secondary, tertiary) so that if the insurance is re-sequenced you don't have to move all of the data. Will assist in prioritizing which insurance is due.
4. Add cell phone number for guarantor.
5. Secondary Employer information - name, address, employer phone/ext, employee work phone/extension
6. We would like a field for the account age at placement.
7. Insurance Company - expand to 30 char
8. Effective date and expiration date for each insurance.
9. Additional insurance phone number (often there is one for eligibility and another for claim status)
10. Insurance Fax number
11. Insurance E-mail Address
12. Insurance Web Site URL
13. Insurance Contact name/ phone number / extension
14. Track procedure codes used to post each payment the data, just change the sequence #.
15. All names should be broken down into first, last, MI with 15 characters for both first and last name.
16. Payer type (HMO, PPO, COMM, Liability, etc)
17. Insured name - break down to last first middle initial
18. Insured DOB
19. Insured Address
20. Insured phone number
21. Insured relation to patient
22. Initial Bill Date
23. Status Date
24. Status Type (examples denied, appealed)
25. Status Code - would store denial codes
26. Total adjustments prior to placements (currently total paid and adjusted in alpha field)
27. Total payments prior to placement
28. Placement histories that can be run by financial class, service type, and by patient type with a balance range.
29. Aged Trial Balance reports.
30. Internal Medicare follow-up with all the basic information required to do follow-up claims on-line.
31. Insurance master change report.
32. Tracking abilities for new business and how much inventory was paid/adjusted/closed for each collector.
33. Tracking of incoming new business and inventory amounts paid/adjusted/closed by collector. Possibly an average inventory for each worker/owner daily for the current month and monthly for historical reference.
34. A few user defined 10-15 character alpha fields with merge code capability.
35. A few user defined 10-15 character numeric fields with merge code capability.
36. Insurance plan code - internal unique identifier length 20
37. Provider unique identifier - HIPAA will require all insurance plans to have a standard unique identifier. Don't have any clue what the length will be.
38. Total adjustments since placement (function key to view from pmt history)
39. Total payments since placement (function key to view from pmt history)
40. Recovery percentage per collector for specified dates.
41. Delinquent payers by client tracking as well as aging by payer.
42. Fax number for guarantor
43. All phone numbers should support international phone numbers
44. All addresses should support international addresses.
45. City, St, and Zip should always be stored separately.
46. All addresses should provide extra address line
47. All amounts associated with an account should support $999,999,999.99
48. Collector profile set-up need modification, possibly a 10 character description and an extended field along with the creation of a new field for team name.
49. Allow up to 4 authorizations with the following information:

· Date of authorization
· Authorization number - Alpha length 20
· Authorization type - (examples Retrocertification, recertification, precertification, authorization)
· Authorized length of stay
· Contact name
· Contact phone number

50. Prorated Amount - total amount estimated to be the insurance's liability
51. Amount placed
52. Current balance
53. Allow for up to 10 description codes for each insurance record. Smart code logic should then let you reference insurance description codes. For example if insurance record 1 has a description code of SP then ….
54. Smart codes for primary balances, secondary balances or the sum of all.
55. A set of fields to store deductible, co-pay & non-covered amounts.
56. Allow for multiple addresses for the guarantor

o Address priority - determines sequence in which addresses should be used
o Address type - alpha length 12 (i.e. temporary, permanent, confidential)
o Street 1 (30 char)
o Street 2 (30 char)
o City (20 char)
o State/Province
o Zip (10 char)
o Country (20 char)
o Return/Stop Mail Indicator
o Expiration Date (track when a temporary address expires)

57. Smart code summaries and better historical information on use of smart codes.
58. Audit trails to allow tracking of movement of accounts through Intellect as it moves from worker to worker, indicating changes that are made and last date that the worker code changed.
59. Ability to track financial class at the payer level and report payments received by the financial class of the payer.
60. Call tracking capabilities.
61. Identity of various Insurance carriers that are available on-line.
62. Assignment of responsible payer in the system.
63. Thresholds placed on accounts based on the age of the account thus presenting it for follow-up if it exceeds the allotted time frame. Reporting capabilities on the percentage of accounts in a queue exceeding the threshold.
64. Identification of accounts that have been set up with promises to pay would help forecast collections and aid in goal setting.
65. Balance tracking capabilities for individual insurances regardless of balance type.
66. A need to track payments by actual payer, financial class of the payer or financial class on the payment.
67. Ability to track an account by owner/collector.
68. Analysis by user as opposed to owner.

Navigating the system

Intelec is a vast system. It is important that a user can determine what is available and where it is. There is a great deal of functionality within Intelec and we must now step back and help our users to better “navigate” the system. What happens when you want to reopen a purged account? Where do you go? What if you have never done this and need to know how to do it? What if you need a report that prints recovery percentage by month of placement? What do we have and what option is it?                  

Manuals are not the answer! We will provide an intelligent, on-line “System Map” that will allow any user to get to the option they need, very quickly. We will also need to tie the options to the authority that a user has for accessing the different areas of the system. The vision is to have several major classifications (e.g. Payments, reports, account entry etc.) and then allow a user to move down through sub-classifications until they get to the option that is required. At that time, we could transfer the user to the appropriate menu. (Starting 4Q 2004)


Support

We will be using the internet to deliver support when it is practical.

• The Q/A database on the iSeries (AS/400) will be replaced by a link on our web site. This will allow faster publishing of questions as well as easier access to the information.

What do our clients have to do to prepare for these changes?

The major files such as the account, note and payment history will be expanded. We are estimating that to have a net impact of about a 10% increase in the size of these files. There will be additional disk utilization and it is recommended that you check your status. It is recommended that you always run at less than 70% of disk utilization. Disk is not expensive and we feel that a small investment on your part is not an unreasonable request.

Based on the today’s cost of hardware and the state-of-the-art technology we offer, we are suggesting that you should strive to have sufficient disk so that your disk utilization is less than 55% with Intelec Release 7.1. (You can check the present value of disk utilization by keying in “WS” at any menu, and looking for “System storage used” or “% system ASP used”)

Some of the real-time, interactive inquiries will take processor capacity. Most of today’s systems are capable of handling complex processing, but you may need to consider memory if you use the new functionality and response is slower than expected for some of the new options. Again, we are not talking about significant costs. Unlike in he past, with the increased pace of our development, you are well advised to stay up-to-date with IBM software (current or no more than 2 releases, preferably 1, prior to the currently supported version of the IBM operating system), and to try to upgrade your processor at least every 24 months.

If you have had any programming that has been done by any party other that Quantrax, we will not be responsible for supporting or advising you on how those changes need to be migrated to the new version. It is very likely that every program that has been done will need to be carefully reviewed for compatibility. Quantrax will not be responsible for documenting the database changes made. We will provide documentation on what we feel are the key changes. With regard to custom programs that were developed by Quantrax, these will me modified at no cost to you as per our standard procedure.


© Quantrax Corporation, Inc. Please sent comments to ranjan@quantrax.com