Exhibit (10)(f)


Pak Ship & Sell (PSS) Application

Reorganization Scope Document

           (See Proposal for Executive Summary and Proposed Services)

GOALS

     o    Design application for long term scalability and growth

     o    Use common design  methodology  to facilitate  easier changes and code
          reusability

     o    Build better security from both corporate and store access

     o    Create a more flexible,  user-customizable  interface so that the user
          has the  ability  to  design  his  own  screen  for  both  shipping  &
          point-of-sale

     o    Enhance  Stor-Pak  Features and  Functionality so that it is used more
          frequently and more accurate

     o    Provide ability to web-enable any components as needed

     o    Design  should  accommodate  multiple-store  scenario and central data
          storage

     o    Start  framework for  Corporate  Data  Warehouse  and future  Intranet
          Infrastructure

     o    Minimize or Eliminate the need for 3rd Party software and integration

     o    Create  real-time  upload  interfaces to major carriers to accommodate
          automated manifesting and package tracking

     o    Reduce support needs by creating more intuitive interface and software
          integration

     o    Standardize on latest  technology  desktop  operating  systems such as
          Windows 2000, while still supporting existing Win95 & Win98 desktops o
          Create  product that can be positively  marketed  along with franchise
          opportunities and possibly offer additional fee services


                                                                   Presented by:

                                                        Raymond James Consulting

                                                                   February 2000



APPLICATION SCOPE OF WORK

PakMail's (P)ak (S)hip & (S)ell (called PSS) Software has some core
functionality that should be retained and enhanced for a newly redesigned
version. The current system will be analyzed and documented from a
user/functional point of view. This documentation will be reviewed with key
PakMail personnel and a determination of what features and functionality to
retain will be determined. Technically, none of the current structure will be
retained. A redesign of both database and application structure is required in
order to meet scalability and growth requirements. These designs will be
discussed in detail later.

PSS also utilizes 3rd party and external software applications that should be
incorporated and/or maintained for the core application. These include:

<PAGE>


         - Accounts Receivable                       - Rate Updates
         - ARS Bin (ARSASD)                          - Rate Print/Calc
         - Custom Labels                             - PSS Online
         - Commissioning                             - Various Import Utilities
         - ZZUpdate                                  - UPS OnLine

These are currently either launched from PSS or called from external
applications, which are started independently from PSS. Need will be determined
and `best design' practices used to determine what to incorporate and what to
leave `as is'. If left `as is', then a redesign to conform to the new structure
may be necessary in order to meet certain technical requirements.

For accounting purposes, analysis should be done to determine if building an
export/interface to existing packages would be worthwhile versus building
individual modules such as A/R. If deemed worthwhile, then an export/interface
will be built in the place of an A/R module.

In addition, there will be a web-enabled process to upload shipping information
to a Federal Express (Fed-Ex) regional server. Specifics should be obtained from
Fed-Ex directly. The connection should accommodate both dial-up and real-time
circuitry through any chosen Internet Service Provider (ISP) for web access.
There may also be a similar module developed by United Parcel Service (UPS) in
the future, so the design should accommodate easy incorporation for additional
module(s).

ASSUMPTIONS

In order to carry out the proposed project plan, several critical assumptions
have been made. If any of these assumptions are incorrect or inaccurately
estimated, then the project plan and budget could be negatively impacted.

     o    PakMail Key Personnel, both at Corporate and Franchise Operations are
          readily available or can be made available with short notice.
     o    PakMail Programming Resource(s) can be freed up and available for at
          least 80% of their time devoted to the project to work at RJC offices.
     o    PakMail can and will provide necessary hardware peripherals that are
          utilized in franchise operations for the duration of the project.
     o    RJC will provide development facilities, equipment and project staff
          for the duration of the project.

DESIGN REQUIREMENTS

Database

The current database design and platform is highly inadequate to accommodate
growth and reporting needs. The database platform will be migrated from the
existing Access '97 databases to utilize MSDE (Microsoft Data Engine). The MSDE
engine is easily portable between different desktops and/or servers and offers
the power needed to facilitate growth. It also allows remote access and
elaborate security schemes to allow only those authorized users to `see' the
data. Currently, user base tops out at approx. 20-30 users, which far exceeds
the normal concurrent PakMail user base.

The franchise (client) database will be redesigned to allow more flexibility and
normalization of data. An index and keying strategy will provide performance and
relational structures to allow for adequate input and reporting of data. The
result of this will be faster, smoother performance from the application side
(GUI) as well as ease of reporting on the back end. In the current database
design, there are many reporting challenges that make it difficult to report
information in a usable format with any performance. Decisions will be made as
to the number of databases to utilize as well as the usable structure of each,
in accordance with application requirements.

A completely new design of a `Corporate Database' will also be done. The purpose
of this database is to reside at the Corporate Offices of PakMail and to retain
information from all franchises concurrently. This makes an assumption that

<PAGE>


PakMail Corporate will build and install an NT server with SQL Server 7.0 for
this purpose. Actual collection of this information and any reporting of same
will be beyond the scope of this phase. Should a second phase follow this
initial project, Corporate-side application items including a company Intranet,
data-mining techniques and administration modules could be addressed at that
time.

Application Infrastructure

The PSS Application itself will undergo massive changes, both on the GUI
(interface) side as well as the rules and validation side (behind the scenes).
The new design will follow a 3-tiered approach, which will create components
used for various processes and input/output (I/O).

A 3 TIER DESIGN IS AS FOLLOWS:

Tier 1 - also known as the GUI (Graphical User Interface)

     The first tier is composed of the screen panels, forms and dialogs that a
user sees and interacts with, in order to provide input and obtain output from
an application. Very little processing other than what is needed to provide
`display' back to the user is done in this layer.

Tier 2 - also known as the Client Layer

     The second or `middle' tier is composed of classes of objects that
determine business rules that govern I/O as well as some data validations as
related to database data, and database object access. Database access is done by
calling server component(s) to access and read the data and then pass this data
as objects back to the front-end (GUI) as required. Other functions are
performed in this layer such as formatting screen output, calculations and other
processes as needed by the GUI. Under this object model, the `server
component(s)' generally perform all database access, security checks and
database-specific processing that is passed back to its caller. The caller is
usuAlly an object within the Client Layer, which requests information from the
server objects. The Server Component(s) access and read the database, and then
return the requested data object(s) back to the Client Layer to be further
processed and passed to the GUI for display. The `Server Component' itself can
be comprised of 1 module or many modules, which perform database I/O. This model
keeps all objects that perform validations and database access separate from the
front-end, thus creating what is called a `thin client'.

Tier 3 - also known as the Database Layer

     The third tier is the actual database and database engine itself. In this
model, it is its own tier due to the fact that by implementing triggers and/or
stored procedures, the database can do a great deal of work on its own.
Performance requirements and optimizations will dictate whether triggers and
stored procedures will be utilized for this application. There may some
processes that would be better suited to be done on the database level rather
than from other layers, however the trade-off is that these items are generally
more difficult to implement and maintain.

This model also accommodates ease of transition into a 4-tier model should
PakMail decide to implement it at a later time. In a 4-tier model, the Client
Layer is broken up into 2 layers, consisting of Client and Server Tiers. The
Server Objects should easily be identified and moved to their own layer allowing
transaction control processes to govern them such as Microsoft Transaction
Server (MTS). In a 4-tier model, the components can all be distributed on
different machines, thus creating an enterprise-wide data distribution network.
This model is generally used in large networks with remote access and the need
to `share' resources with other groups and applications. It may be some time
before PakMail is in a position to do this, but the infrastructure will support
making the transition an easy and painless one.

How does the 3-tier Model work for PSS?

Let's take a detailed look at the 3-tier architecture and plug in the PSS
components as they exist today.

<PAGE>


Tier 1 - GUI
------------
     The GUI of PSS will change dramatically in order to create a more
intuitive, robust application that users will enjoy using. The current GUI
requires extensive training and computer literacy to be able to operate
efficiently. A new GUI will incorporate either a 100% browser-based interface
that can be operated very similar to any internet application, OR will consist
of a windows standard application `look-and-feel' so that users can move around
instinctively, as most are already somewhat familiar with Microsoft-based
applications. The use of standard controls and drop-down menus will facilitate
ease-of-use and procedure flow. The actual interface design will be determined
in the `Discovery' phase of the project after various PakMail contacts have been
interviewed including both corporate employees and franchise personnel.

Tier 2 - Client
---------------
     The client layer will consist of objects for carriers, rates, services,
lists, validations of input, and point-of-sale rules. Business Rule enforcement
such as types of transactions, package weights and dimensions, zip code/zone
validation, and printing as well as many other business-specific operations will
be done in this layer as called from the GUI. Different inputs determine what
actions occur in the client layer and the client layer determines when to go to
the database and what to put into or bring back from the database. In PSS, as
transactions occur from the GUI, those transactions will utilize objects in the
client layer to complete processing.

Tier 3 - Database
-----------------
     The database is the object that holds or retains all the actual data
elements needed to continue the business. The data is placed in objects called
tables, which have a specific structure to accommodate various accesses and
joins to other data. Some of these tables will contain codes, descriptions,
customer, account, company, and transaction data that when joined together
create a dataset that can be called information. Data is simply data until it is
formatted into something useful that someone can read and interpret. The purpose
of the database is to store this useless data in a specified format and the
purpose of the application is to format it so that it becomes information. In
required cases, the database also has the ability to cascade changes to other
tables and update or arrange data in ways to make it more accessible. It may
also make changes to itself in order to enforce integrity of the data it
contains. In other words, data from one table may be a subset of data in
another, and in instances where that data is changed or deleted, the database
may want to affect both tables in order for the data to achieve desired results.
This is commonly done with triggers and stored procedures, which can interact on
a database and not affect any other layer. These types of processes are
generally implemented one time and require little, if any maintenance.

FUTURE CONSIDERATIONS

This project will reengineer PakMail's PSS Application to place it in the
forefront of today's technology. The architecture will be easily maintained and
the interface should be easier to navigate and learn, thus reducing training
time required to operate it.

With this application infrastructure in place, the next logical steps to
implement would be to establish a Corporate Database Server (Warehouse) and a
Corporate Intranet to act as an information conduit to these resources. This
would give PakMail Corporate the ability to collect information from all
franchise operations on an automated basis (Royalties, Sales & Marketing info)
and be able to apply either packaged or customized mining tools to analyze the
data. Interfaces can be developed to `feed' this data to other systems and/or
applications easily. Because the database server will be based on Microsoft's
SQL Server, most 3rd party tools can be utilized to report on the data in both
text and graphical context. Utilizing these 3rd party tools can reduce costs
involved with custom development and maintenance; provided satisfactory tools
can be found in the open market.

With the advent of a real-time Corporate Intranet, PakMail Corporate would be
able to share information with franchises on a much more efficient basis and
even provide additional services that could be an added revenue stream. Web
pages could share and display information from the centralized database as
PakMail warrants. Email services could be brought in-house, as well as home

<PAGE>


pages for public consumption. An Internet/Intranet site management scheme can be
initialized to allow PakMail to control both sides of the network; both public
and private. A public site can be used similarly to the T3 implementation of a
home page and informational pages, as well as any additional items that PakMail
deems necessary which PakMail's own staff can create and administer on a more
usable time frame with no reliance on a 3rd Party.

The execution of the building of this infrastructure places PakMail's destiny in
their own hands and of course, RJC can assist with any future implementations
and utilization in all areas of technology. Once the infrastructure is built,
and PakMail's staff is trained to continue with it, PakMail should have no more
dependencies on 3rd Parties for years to come.

PROJECT PLAN AND DATE RANGE

March 6 - Project Commences

Tasks:

Documentation
     Mar 6 - 24          Analyze and document existing applications from a
                         user-perspective. Using document and key PakMail
                         personnel, determine what features and functionality
                         should be retained in new design. Also determine if
                         some functionality should change in some way or be
                         enhanced to meet needs.

Discovery Phase
     Mar 6 - Mar 24      Interview key corporate employees, franchisees and
                         store employees. Spend time in actual stores to observe
                         operations and business flow. Corporate personnel
                         should choose franchisees and stores. Determine what
                         GUI to use and development platform considering any
                         corporate hardware/software needs including 3rd party
                         controls, etc. Acquire hardware knowledge to be used in
                         stores ie; desktops, printers, scanners, fax, scales,
                         etc. and retrieve a sample of each for development and
                         testing. Final output should be detailed Functional
                         Specification requiring corporate signoff before
                         development begins.

                         Start client Database redesign using the existing
                         databases as a foundation for needed data elements.
                         Structure may change after Discovery is complete, but
                         should be able to start a foundation to build on.

Design Phase
   Mar 20 - Apr 14       Set up final development environment and project space.
                         Lay out and create final client database design and
                         identify Component objects. Determine and design
                         external and 3rd party app usage including
                         communications, web upload and printing/faxing. Design
                         GUI `look-and-feel' to carry on throughout development
                         process. Development PROTOTYPE and demo to key
                         corporate personnel for final acceptance of GUI. This
                         could be one screen form with minimal interaction with
                         controls. Design Corporate Database (not critical at
                         this point).


Development Phase
   Apr 17 - Jun 23       Develop and unit test actual components from physical
                         designs. Adhere to standards for COM model and Visual
                         Basic or Visual Interdev environments. Provide interim
                         `releases' as possible for internal testing. Analyze
                         and create a conversion program to move existing data
                         into the new environment.

                         Create test specifications and scripts for Quality
                         Assurance (QA), QA product and prepare for
                         stabilization. Create User and Technical documentation
                         for product as to be used by PakMail Corporate and
                         clients. Output should be a documented ALPHA release.

<PAGE>


Stabilization Phase
    Jun 26 - Jul 14      Finalize and stabilize product through extensive test
                         scripting and load testing in a `normal' store hardware
                         scenario. Create installation routines and test.
                         Prepare for initial `pilot' to corporate and store
                         (BETA). Implement corporate testing installation if
                         stability warrants. Include corporate and other key
                         personnel for testing. Verify hardware needs and
                         prepare `pilot' plan. Perform site prep for BETA.

Beta Implementation
    Jul 17 - Jul 28      Client Store BETA implementation. Corporate should
                         choose store and provide training and/or preparation
                         for personnel. Run software for 2 weeks and get
                         constant feedback. Correct and turn around problems
                         quickly. Transfer product and development knowledge to
                         corporate personnel for short-term turnover and
                         long-term maintenance. Prepare logistics for
                         implementation and rollout plan. Final Release and
                         Rollout Jul 31 Begin rollout.

PERSONNEL REQUIREMENTS

Mar 6 - Mar 24      Business Analyst and/or Technical Writer for initial
                    analysis and documentation of existing system.

Mar 6 - Mar 17      Business Analyst and/or Developer/Analyst for Requirements
                    Analysis Database Architect for initial client database
                    overhaul Data Modeler to identify data paths and
                    relationships

Mar 20 - Apr 14     GUI Designer for interface design look-and-feel COM
                    Architect for component identification, reusables and Object
                    Design Database Architect for Corporate Database design

Apr 17 - Jun 23     VB or HTML/ASP Developers (2) for actual coding and unit
                    testing Crystal Reports programmer for reporting, if utilize
                    Crystal Testing/QA Architect and Coordinator (May 22)
                    Technical Writer (Jun 5)

Jun 26 - Jul 14     Installshield or PC Install Programmer for installation
                    routines Developer and/or Analyst for corporate site prep
                    and implementation

Jul 17 - Jul 28     Developer(s) and/or Analyst for BETA implementation,
                    bug-fixes and wrap up

Jul 31 - Sep 1      Developer(s) for warranty period


A GRAPHIC WAS REMOVED WHICH ILLUSTRATED THE ABOVE TIME LINE.



<PAGE>



Risk Factors in adopting Accelerated Timeline


1) Design time is reduced, which would mean that some existing designs would
have to be carried over in order to save time. Some of these designs will cause
the overall product to be less robust and harder to integrate.

2) Design and Development phases overlap causing some development to have to be
redone to accommodate new designs. This can often lead to poor quality,
increased time and frustrated team members.

3) The QA process and the ALPHA release overlap, which means that quality will
be compromised for the ALPHA release and changes will be harder to implement due
to different teams performing testing. In other words, this creates a `dual
update' scenario for developers which is hard to manage and even harder to
consolidate changes.

4) The Documentation overlaps with ALPHA Release, which actually makes the
documenting process more difficult, as the software changes during the QA and
ALPHA processes.

5) The BETA Release is done earlier, possibly before the release is actually
'ready' to BETA; compromising quality and 'first impression'.

6) NO Contingency time is built into the entire process.


Although the Accelerated Timeline offers some significant timesavings on the
surface, in reality, the risk can create an even longer timeline due to change
control and quality issues. It may save time in one phase, but then increase
(possibly double) in another phase due to unforeseen problems or obstacles,
which always exist.

It has been our experience that 100% of projects require some contingency due to
personnel issues, technical issues or a combination of the two, and we do not
recommend using this approach. It is included only as a risk analysis
demonstrating the dangers involved in `cutting corners'.


<PAGE>


PROJECT FEES

RJC is proposing to assume much of the risk of this engagement by fixing the
price of each of the major phases: Discovery/Design, Construction and
Stabilization. The advantages to PakMail of this approach is that budget
constraints are met, and that RJC, as the solution provider, is committed to
specific deliverables, not to working hours for an agreed-upon rate.

The "fixed-by-phase" pricing approach allows both RJC and PakMail to limit the
risk of the unknowns that exist early in the project, while also controlling the
cost of contingency time. The process is as follows:

     1.   An estimate is given below for the project as a whole, for budgeting
          and planning purposes,
     2.   A fixed price for the Discovery/Design phase is also below in two
          phases: Discovery/Conceptual Design (through completion of functional
          specification) and Technical Design (through completion of technical
          specification and prototype)
     3.   A fixed fee for the Construction phase will be presented before the
          end of the Design phase.
     4.   A fixed fee for the Stabilization phase will be presented before the
          end of the Construction phase.

The overall estimate for the project as defined in this document is between
$185,000 and $194,000. For the first phase (Discovery/ Conceptual Design), the
fixed fee is $29,800. For the second phase (Technical Design), the fixed fee is
$31,000.


Service Delivery Credits

Based on our discussions regarding earlier delivery issues, RJC will credit a
total of $7,500 to PakMail over the estimated project lifecycle, prorated
approximately by 2-week billing period. The total credit will bring the net fees
for the entire project to between $177,500 and $186,500. This amounts to
approximately $682 per invoice over 11 billing periods.




Invoicing

Invoicing for fixed-fee projects is generally done bi-weekly or monthly in
segments that reflect the "burn rate", or usage of resources. Upon approval of
this scope document, RJC and PakMail will agree on an invoicing schedule for the
Discovery/Design phase. The table below reflect a billing schedule based on a
start date of 3/6/2000 and using a conservative total project cost of $185,600
(net of credits applied as described in the previous section):
<TABLE>
<CAPTION>

                 Start                                                                                           End
Invoice Period  3/3/00
<S>                <C>  <C>      <C>     <C>      <C>     <C>       <C>       <C>      <C>       <C>       <C>      <C>
Ending               0  3/17/00  3/31/00 4/14/00  4/28/00 5/12/00   5/26/00   6/9/00   6/23/00    7/7/00   7/21/00  7/31/00
Net Invoice
Amount               0  $19,400  $19,400 $20,333  $20,333 $20,334   $20,333   $20,333  $20,334    $9,500    $9,500   $5,800
Cumulative           0  $19,400  $38,800 $59,133  $79,466 $99,800  $120,133  $140,466 $160,800  $170,300  $179,800 $185,600
</TABLE>


<PAGE>


Note that after the period ending 4/14/2000, amounts shown above are estimates
only. The fixed fee for the next phase will cover the period roughly after
4/14/2000 until the end of Construction, which is planned to be completed
6/23/2000.

A graphic was removed which illustrates these numbers:



<PAGE>


SCOPE DOCUMENT SIGN OFF

The Vision/Scope Document for PakMail / PSS Redesign is accepted by PakMail
Product and Program Managers. The PSS Team is authorized to baseline the
Vision/Scope Document and proceed with the Planning activities and draft the
necessary Functional Specifications and Design Documents.




----------------------------------------               -------------------------
David Foley, SDD                                                 Date
Solution Development Director


----------------------------------------               -------------------------
Alan Bowman, BSD                                                 Date
Business Solutions Director


----------------------------------------               -------------------------
Vince A. Holt, Sr. Consultant                                    Date
Program Manager - Denver


----------------------------------------               -------------------------
John Kelly                                                       Date
Product Manager - CEO, PakMail


----------------------------------------               -------------------------
Evan Lasky                                                       Date
Program Sponsor - COO, PakMail

----------------------------------------               -------------------------
Debra Carlson                                                    Date
Project Contact - PakMail IT Manager