1. User Pays User Group Monday 2 nd June 2008

2. 2 Today’s Agenda  Introduction (HB)  Review of minutes & actions (TD)  Contractual Change  IAD performance standards proposals (AM)  Proposal for contract change (RM, CB, all)  Next steps (GF)  Terms of Reference  Feedback on draft ToR (GF, all)  Next steps (GF, all)  Updates from xoserve  Operational update (DA)  IAD update (DA)  Proposed Process for Managing User Pays Systems and Service Enhancements (GF, all)  High level timeline (HB)  AOB (all)  Close (HB)

3. Contractual Change

4. 4 IAD performance standard proposals  Background  Core Hours  Availability  Data re-fresh

5. 5 xoserve proposal  Background: feedback from users that xoserve need to provide increased commitment for Core Hours and data re-fresh frequency  Currently:  Operational hours defined as 06:00 – 22:00 Monday to Saturday excluding bank and public holidays  Core Hours (against which performance will be measured for liabilities) are 09:00 – 17:00 each Business Day  Performance standard of 95% availability during Core Hours  Operationally data re-fresh is daily  Core measure (against which performance is measured) data re-fresh must not be later than 4 Business Days

6. 6 xoserve proposal - IAD Core Hours  Aim: to provide increased service provision with little or no impact to price  Core Hours proposed as:  08:00 to 20:00 Monday to Friday (Business Days)  08:00 to 12:00 Saturday (excluding Christmas or New Year where these fall on a Saturday)  IAD operational hours are still 06:00 to 22:00 Monday to Saturday (excluding bank and public holidays)

7. 7 Existing Arrangements - IAD availability  The performance standard for availability is currently 95% of Core Hours  Below this performance, for Unplanned Downtime reductions in charges are currently made as follows: Unplanned downtimeReduction applied to monthly charge 5% or less0% 5.01 – 10%(8hrs*)20% 10.01 – 15% (16hrs*)35% 15.01 – 20% (24hrs*)50% 20.01 – 30% (32hrs*)60% 30.01 – 50% (48hrs*)70% More than 50% (80*)90% *hrs based upon a 160 hour month (4 weeks, 20 business days)

8. 8 xoserve proposal - IAD availability  The performance standard for availability will be increased to 97% against the proposed Core Hours  Below this performance, for Unplanned Downtime, reductions in charges will be made as follows: Unplanned downtimeReduction applied to monthly charge 3% or less0% 3.01 - 5% (7.68hrs*)5% 5.01 – 10%(12.80hrs*)15% 10.01 – 15% (25.60hrs*)25% 15.01 – 20% (38.40hrs*)40% 20.01 – 30% (51.20hrs*)50% 30.01 – 50% (76.80hrs*)60% More than 50% (128hrs*)80% *based upon a 256hr month (4 weeks, 4 Saturdays)

9. 9 xoserve proposal – IAD availability Unplanned downtime within core hours of a day: Current termsProposed terms 4 continuous hours outage, reduction in charges of 50% of daily failure charge rate 4 continuous hours outage. reduction in charges of 50% of daily failure charge rate 8 continuous hours outage, reduction in charges of 100% of daily failure charge rate plus liquidated damages of 25% of daily failure charge rate 6 hours continuous outage, reduction in charges of 100% of daily failure charge rate (proposed change in order to maintain appropriate incentives) In the event the IAD availability performance measure is satisfied in a calendar month, but:

10. 10 xoserve proposal - IAD re-fresh  Performance measure to ensure the data on the IAD system is updated within 2 Business Days following date of receipt and acceptance by xoserve of such criteria  Improvement against present standard (4 days)  Where not met, charges reduced by 50% of the relevant Daily Failure Charge Rate – same as present arrangements  Operationally, data re-fresh is daily

11. 11 xoserve proposal - summary  Extending Core Hours, Availability and Data re-fresh meets customers requirements as stated at the April meeting  Extending Core Hours, Availability and Data re-fresh standards increases xoserve’s costs and risk exposure  xoserve consider that the extension to Core Hours, Availability and Data re-fresh can be accommodated by reducing the liability risk exposure rather than by increasing the charges

12. 12 xoserve proposal - summary  Views?  Possible next steps:  Transporter to incorporate within SPAA change  Performance standards incorporated within Schedule 4

13. 13 Contractual change  Proposal submitted by Rosie McGlynn and Colette Baldwin

14. Terms of Reference

15. xoserve update

16. Operational Update

17. 17 Current demand for Non-Code services ServiceNumber Invoiced for April Forecast for April Commentary IAD10,04712,500Still receiving new requests for IAD TelephonesInvoiced as Bands In line with forecasts DVD00Not sent out this month as quarterly Email105169Slow start to the month AQ spec calc2,900212,934Usage is seasonal so expected limited use during April Portfolio reports8370Report request higher than forecast Value of non-Code sales for April £236,000 against forecast of £274,000

18. 18 April’s Non-Code Service KPIs ServiceKPIsExplanation for other than Green IAD Telephones DVDNo DVD this month as only quarterly Email AQ spec calc Portfolio reportsRegistered user portfolio report not complete for some customers. Data portfolio snap shot not sent to some customers. Non-Code services Invoice issued on 20th May Payment due date is 17th June

19. 19 Interruptions to Non-Code Services during May  Tuesday 6 th May  Telephone Service unavailable for eight hours due to suspected server problem  Sunday 11 th May  IAD unavailable on 11 th May due to server failure as a result of air conditioning problems in data centre. IAD data re-fresh was three days late for Monday 12 th May, fully recovered on Tuesday 13 th May  Wednesday 14 th May  xoserve call centre employees could not access Sites and Meters so were unable to deal with calls and thus provide the Telephone Service and E Mail reporting services. Six hour outage to Telephone Service Note: calls made during Telephone Service outage periods do not count towards usage

20. IAD Update

21. 21 IAD users User type Provision ruleContractNo of Accounts ShipperGT Licence Condition 31 and UNC permit release of data. User Pays contract 10,500 NetworkUNC permits release of dataASA (note ASA refers to User Pays contract Schedule 4 and ACS for charging and service delivery) MEUsGas Act. Note Shippers provide permission to access data User Pays contract iGTsUnder contract to measure performance of the services (2 accounts provided) Contract between xoserve and iGTs 12 Govt orgsSocial Security Administration Act 1992, Section 109B None 50 Ofgem E/watch Industry regulators licensingNone 30

22. IAD Enhancements

23. 23 IAD Enhancements  Enhancements to improve the IAD service were identified in mid 2006  Requirements captured and design solutions developed pre User Pays  Implementation had to be scheduled around a number of other key systems changes, hence now planned for 2008 deployment  As a result, changes proposed for implementation during transition of User Pays arrangements  Combination of feedback from users and the results of testing have identified the need for further review prior to implementation  What were the objectives?  How were these to be satisfied?  Issues and implications?

24. 24 IAD Enhancements  Objective  Improved service for IAD password re-sets  How delivered  user driven password re-set functionality  Two options:  Users set security information (series of questions)  Auto email response “ping-back” service  Issues:  Questions – nature, number and security of data  Auto email – slower delivery of service  Frequency of system initiated password re-set

25. 25 IAD Enhancements  Objective  IAD system performance stability  How delivered  ability to monitor activity at transactional level  Implications  none on users  Code to be deployed, but later than scheduled

26. 26 IAD Enhancements  Objective  Improved IAD security  How delivered  Single user log-on functionality  Issues and implications:  Consider implications of local (to user) network failure  Web browser discrepancies  Change still under review

27. 27 IAD Enhancements  Summary:  Outage on 21/22 June cancelled  Transaction monitoring to be implemented  Password re-set functionality – need to agree preferred solution and implement  Timescales for implementation to be advised.  Note:  DN interruption functionality was implemented during the outage on 17 th /18 th May  Single/ Concurrent User was deferred  Outage planned for 1 st June to rectify minor issues with data search and display functionality

28. Proposed Process for Managing User Pays Systems and Service Enhancements

29. 29 Proposed User Pays User Group role in change to service provision Change typeResponsibleAccountableConsultedInformed User Pays delivery systems for all non- Code services XX ACS ModificationXX Legislative and regulatory change XX UNC ModificationXX Note: Contract change process not yet included here as under separate development

30. 30 Proposed Process for non-code services Proposed system/service enhancement to UPUG UPUG discussion Feasibility study Commitment to proceed Project set up to deliver. Will keep UPUG informed Inform other industry forums if required Process excludes Mods and Regulatory driven change However, xoserve will make UPUG aware of any impacts to services due to Mods or Regulatory change

31. 31 User Pays User Group role in change  UP system change  Full discussion with UPUG from initial idea to any implementation. Change can be proposed by any party  ACS modification  Sharing of information at earliest opportunity  Legislative and regulatory change  Sharing of information at earliest opportunity. Nature of change depends upon scope for consultation / notification  UNC modifications  Kept under review for any implications on User Pays services (code or non-code)

32. Time Line

33. 33 High Level Time Line 7 Lessons Learned Governance: 20th Invoices issued 17 th Invoice payment tbc July tbc Aug tbc2ndUser Pays User Group mtgs Operational: Review forecast under/over recovery/ACS implications Establish TOR for UPUG Develop revised Ts and Cs SeptJuneMayActivity IAD transactional monitoring

34. AOB