Message-ID: <20091576.1075844283399.JavaMail.evans@thyme> Date: Fri, 17 Nov 2000 01:27:00 -0800 (PST) From: terry.lehn@enron.com To: lisa.sawyer@enron.com Subject: eCommerce ideas Cc: steve.hotte@enron.com, julia.white@enron.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: steve.hotte@enron.com, julia.white@enron.com X-From: Terry Lehn X-To: Lisa Sawyer X-cc: Steve Hotte, Julia White X-bcc: X-Folder: \Rodney_Hayslett_Dec2000\Notes Folders\All documents X-Origin: HAYSLETT-R X-FileName: rhaysle.nsf 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