Lisa,

I decide to jot down some of my ideas for our eCommerce strategy.  For the 
most part, these are "brainstorming fodder".  Here goes:

Mindset:  If it can be sold, it can done via the Internet.
Mindset:  If it is currently done on a form, a forms-based electronic version 
should be created.
Provide our customers, operators with transaction preparation software which 
can be run on a desktop or notebook computer and a PDA.  Ensure that a 
synching mechanism allows for movement of the transaction to and from the 
PDA.  Use models such as MS Money for the PocketPC.  Give away this software 
and the pre-programmed PDA.
Allow feeding of the above transactions into an asynchronous process on our 
side.  This will help deal with unreliable connectivity.  Customers should be 
able to inspect the progress what is in our system.
Provide "wireless snippets" of our current applications.  This means 
extracting key decision points so that internal people or our customer can 
make them from anywhere.  For example, the customer would be able to confirm 
a pre-arranged capacity release deal.  Another example: contract request 
approvals could be moved to cell phones or PDAs.  This would speed our 
business processes.
Provide "respondable" notifications.  Internal people or our customer would 
subscribe to the types they wish to receive.  For example, a customer could 
be notified of a higher bid on a biddable capacity release offer and have the 
opportunity to bid higher via her cell phone or PDA.  Another example:  
support personnel could be notified of an unresponsive server and have the 
ability to initiate a reboot from her cell phone or PDA.
Base most or all of our Web pages on XML or provide an XML download (in 
addition to the current comma-delimited choice).  We should lead the way in 
identifying the necessary "vocabularies" for GISB data sets and data not 
currently defined by GISB.  This would permit the customer to move the data 
into any of several XML-capable tools such as spreadsheets, word processors 
and so on.  The more sophisticated customer may use the Web page address to 
extract data into their own custom apps.
Implement the supernom across ETS pipelines.
Is there an opportunity for us to overbook as do the airlines?
Expose some of our systems functionality via remote method calls using Simple 
Object Access Protocol (SOAP).  SOAP is based on the Internet standards of 
HTTP and XML and is, therefore, platform/ technology agnostic.  For example, 
we may allow the customer to obtain certain non-proprietary data base 
information such as name and legal descriptions of point locations, legal 
entity names, tax authorities, lat/long and so on.  We could get more 
adventurous by exposing such things as capacity currently not nominated ahead 
of the nom deadline.
Provide the customer the ability to assemble a contract electronically with 
pre-approved terms and conditions, locations and alternate locations, etc.
Provide annual usage statements to assist the customer with their planning.
Provide graphical displays of certain tabular data.  For example, we might 
show the customer actual versus nominated, nominated vs. MDQ, monthly usage 
charts, etc.
Consider where we could or should apply fees to some of the above services.

I believe I have a few more of these that I haven't yet extracted.  I hope 
these can be useful in today's session.

Terry