1 Overview

The General Services Administration (GSA), Federal Acquisition Service (FAS), Office of Telecommunications Services (OTS) created the Enterprise Infrastructure Solutions (EIS) program to provide an acquisition vehicle for agency customers across the Federal Government and other eligible users, to acquire simple to complex telecommunications and networking infrastructure services from one or more contractors. This guide provides an overview of all EIS Management and Operations (MOPS) related processes, such as ordering, billing, Service Level Agreement (SLA) management, disputes and administration. For additional information on MOPS processes please see EIS contracts Sections E, G, and J.2. This MOPS Handbook is not a stand-alone reference – we recommend that the reader become familiar with the EIS contracts and other EIS guides, handbooks and videos that address acquisition planning, transition, pricing, services and systems. A full listing of resources, for further information, is included in Appendix F. This MOPS Handbook may be revised from time to time. Updates to this Handbook, when they occur, will be available on the GSA website at http://www.gsa.gov/eis.

1.1 Intended Audience

This MOPS Handbook is intended for use by agency Program Management Office (PMO) personnel, agency personnel who support the Ordering Contracting Officer (OCO) and/or Contracting Officer’s Representative (COR), and other agency personnel who need to understand the EIS management and operations process.

Information to assist customer agencies in using the EIS contracts is available online at http://www.gsa.gov/eis. Subscribe to this page to be notified as new resources become available and to receive announcements as they are released. The site includes the EIS contracts and contract modifications, lists of the industry partners and many other useful documents.

1.2 Purpose

This MOPS Handbook focuses on implementation and operations functional tasks. It lays the foundation to assist agency staff in knowing the necessary ordering and administration processes to effectively use the EIS contracts. However, agency staff, especially OCOs, should read the EIS contracts to understand the scope of the contract and service offerings. The MOPS Handbook does not supplant the EIS contracts. The EIS contracts take precedence for management and operations guidance for contract compliance.

A high level view of EIS functional tasks is shown in Figure 1 below. Acquisition Planning and Decision/Award functional tasks are briefly covered in this guide with more detailed information provided in the Fair Opportunity and Ordering Guide (FOOG).

Figure 1 EIS Functional Tasks

2 EIS Contracts Information

EIS is a multiple award, Indefinite Delivery Indefinite Quantity (IDIQ), task order, contract vehicle. A task order is the official contractual mechanism agencies use to order services under EIS. All task orders are subject to fair opportunity as defined in Federal Acquisition Regulation (FAR) 16.505. An agency OCO selects a contractor, awards task orders, and initiates service orders. Agencies are directly billed and manage their own services throughout the lifecycle of the task order.

The EIS contracts comprehensively address federal agencies’ requirements for telecommunications and information technology infrastructure. EIS is the follow-on acquisition vehicle for Networx, Washington Interagency Telecommunications System (WITS) 3, GSA’s Regional local service contracts, and other current telecommunications contracts. EIS contracts were awarded on July 31, 2017 with a period of performance of 15 years (if all options are exercised). For a list of awarded contractors and the details of EIS contracts and services awarded see the EIS site at http://www.gsa.gov/eis.

3 Roles and Responsibilities

3.1 Agency Role

Agency responsibilities for management and operations are defined in the EIS contracts Section G.2.2.1. The following is a high-level summary of an agency’s responsibilities:

1. Place Task Orders (TO) according to FAR Subpart 16.505, and service orders in accordance with the terms and conditions of the EIS contract.

2. Accept or reject the services rendered by the contractor under task and service orders in accordance with EIS contracts Section E.2.2, “EIS Services Verification Testing” and coordinate corrective actions with the contractor and GSA if required.

3. Coordinate resources to facilitate scheduling and communications for implementing and maintaining service. This includes:

a) Identify the agency’s Local Government Contacts (LGCs) for each location involved in a particular project or other activity. The contractor will capture the LGC and reflect it in the Service Order Completion Notice (SOCN), thereby enabling the agency to track the LGC from order to SOCN to inventory for more accurate historical records.

b) Monitor and facilitate coordination between the contractor and LGC and other agency contractors and service providers as appropriate.

c) Coordinate with LGCs and with other contractor(s) who are providing the location with telephone switching or other telecommunications facilities, upon notification by the contractor of changes regarding the date of scheduled activities or site requirements.

d) Make arrangements for the entry of service provider technicians into site to include any special access requirements for the site.

4. Review, accept or reject, and pay for services.

5. Notify the contractor of billing discrepancies and facilitate the resolution thereof.

6. Submit the Service Level Agreement Credit Request (SLACR) to the contractor and monitor the issuance of SLA credits. In the event of issues that require escalation, the agency may contact GSA for assistance http://www.gsa.gov/eis.

7. Fulfill any additional roles and responsibilities contained in the Delegation of Procurement Authority (DPA) issued by a GSA Contracting Officer (GSA CO) to an agency OCO in accordance with FAR 1.601. The key official representing the agency is an OCO or an authorized official (hereinafter referred to as “OCO”).

8. Fulfill any additional roles and responsibilities contained in the Contracting Officer’s Representative (COR) Designation Letter associated with the corresponding task order.

3.1.1 OCO Duties

The OCO duties include, but are not limited to, those specified in the DPA. For additional DPA information, go to http://www.gsa.gov/eis. Only the OCO has the authority to award/modify task orders and obligate funds for its agency. The OCO for each Task Order (TO) may designate COR(s), or ordering officials to initiate service orders for services already specified and money obligated for in the TO.

3.1.2 COR Duties

The COR duties and responsibilities may include, but are not limited to the following:

1. Understand the responsibilities and limits delegated by the OCO

2. Understand the contractor’s ordering procedures and complete contractor-provided training related to the placement of orders

3. Confirm funding availability in the task order prior to issuing Service Orders (SOs)

4. Coordinate with the appropriate agency budget and finance offices and the OCO to execute processes and internal controls to support funding availability and to comply with the Anti-deficiency Act (31. U.S.C 1341) and/or other applicable laws regarding funding

5. Place SOs under a TO using the appropriate billing codes and monitor implementation

6. Accept services ordered and verify that services meet technical requirements within three calendar days (See EIS Contract Section E.2.2.5).

7. Execute other duties (e.g. billing disputes, performance monitoring), as defined by the OCO

3.2 GSA Role

GSA’s primary role is contract administration. GSA is responsible for administering the EIS contracts and will modify the contracts as necessary. In addition, GSA will:

8. Ensure compliance with contract requirements

9. Delegate procurement authority to agencies to authorize OCOs to place TOs

10. Place TOs on the agency’s behalf, if so requested

11. Assist in resolving conflicts between the contractor and the agency if necessary

3.2.1 GSA Contracting Officer (CO)

The GSA CO has overall responsibility for administering the contracts. The right to issue contract modifications, change the terms and conditions of the contracts, terminate the contracts, delegate procurement authority to agency OCOs, and exercise option renewals is reserved solely for the GSA CO unless otherwise delegated in writing.

3.2.2 GSA Program Manager

The GSA Program Manager provides centralized technical oversight and management of the EIS contracts.

3.2.3 GSA Contracting Officer’s Representative (COR)

A GSA COR may be designated by the GSA CO to monitor certain technical aspects of the contract. Actions within the purview of the GSA COR include:

1. Ensure that the contractor meets the technical requirements of the contract

2. Inspect contract level deliverables

3. Perform or direct inspections necessary to verify and validate contract level service delivery under the contract

4. Monitor the contractor’s performance under the contract, including SLA compliance, and notify the contractor, the GSA CO, and/or the agency OCO of any deficiencies observed

5. Track contract modifications

The COR’s authority does not include the ability to authorize work not already in the contract or to modify the terms and conditions of the contract.

3.2.4 GSA Customer Support

The Office of Telecommunications Services (OTS) is committed to providing timely and responsive customer service. The focus and priority is to be a business partner supporting federal agencies purchasing telecommunications and networking infrastructure services.

OTS also has dedicated teams of Agency Managers who have the overall responsibility for GSA’s support to assist agencies with acquisition planning and execution efforts. OTS has dedicated teams of Technology Service Managers (TSM) who are prepared to assist agencies with post-acquisition operational efforts such as coordinating with contractors. For more information, please visit the website http://www.gsa.gov/portal/category/105587.

4 Interactions

There are three main entities (the agencies, the contractors and GSA) that interact during the implementation and operations activities associated with the EIS contracts. Figure 2 depicts the high-level implementation and operations interactions among the entities. Brief descriptions are included in the figure. Details are provided in the remaining sections of the Handbook.

Figure 2 Implementation and Operations

5 Implementation

This section describes the concepts and key functional tasks for implementation of EIS services. The key tasks include account management; order processing, order notifications, testing and acceptance of EIS services.

5.1 Task Orders

Additional guidance related to issuance of Task Orders (TOs) is available in the Fair Opportunity and Ordering Guide (FOOG) at http://www.gsa.gov/eistransition.

5.1.1 Temporary Discounts

Under EIS, all items in the pricing tables include a Price Start Date and Price Stop Date which, together, indicate the effective dates for a given price on a given CLIN/ICB Case. By design, these dates are intended to allow for routine price changes but they can also be used to capture temporary discounts applied to a given Task Order.

For example, if the contractor and agency agree that the MRC CLIN SV00001 is normally priced at $50/month but will be discounted to $40/month for the first six months of the TO, and assuming the TO begins on 01/01/2020 and ends on 12/31/2021, for this CLIN, the pricing table would have two lines of data:

1. $40 from 2020-01-01 to 2020-06-30

2. $50 from 2020-07-01 to 2021-12-31

Using this approach, GSA Conexus will be able to accurately predict the expected charges for each month and more readily support agencies in reviewing, analyzing, and paying their invoices in a timely manner.

5.1.1.1 Waiving Charges to Create Temporary Discounts

Although the standard process for creating temporary discounts is to use time-based pricing, in cases where the agreed discount is to provide the service for free for a set period of time, the contractor may also effect the discount via charge waiving (see Section 6.2.1.2 Waived Charges). While contractually allowed, this approach is not the preferred mechanism as it complicates data analysis and financial planning. The agency should consider this when negotiating discounts. It may better serve the agencies needs to dictate the specific discounting mechanism in the TO.

5.2 Administrative Data

To facilitate ordering of services, agencies must provide key data about the agency and TO in order to establish appropriate accounts within the contractor’s systems.

Data the Agency Must Provide to the Contractor:

· Services specified in the TO

· Any TO-Unique CLINs (TUCs) and Individual Case Basis (ICB) data

· Any TO-unique Key Performance Indicators (KPIs) and Service Level Agreements (SLAs)

· Contact information for agency officials such as OCO and COR

· Role-Based Access Control (RBAC) information for agency personnel accessing the contractor’s systems

All of the above with the exception of the last (RBAC information), are included in the TO document(s) or in required formal communications from the agency OCO (e.g., COR Designation Letters) to the contractor and need not be supplied separately.

The contractor is required to obtain RBAC information to allow only authorized users with appropriate permissions access to its Business Support System (BSS). These permissions include but are not limited to, the ability to place orders and research orders, billing, inventory, and performance information. The contractor will collect RBAC information from the agency and may specify the format and means in which it is provided unless restricted from doing so in the TO.

Data the Agency Can Expect from the Contractor:

· Account credentials

· One or more invoice account number(s) associated with a TO

5.2.1 Agency Hierarchy Codes

The Agency Hierarchy Code (AHC) is a 28-character internal government accounting code that is tracked for all services from order submission through disconnection. Under EIS, no SO may be processed without an AHC regardless of how the order is placed. Agencies must provide an AHC for each line item on an order, although they may simply provide one AHC for the order and instruct the contractor to apply it to all line items. Contractors are required to capture an AHC and reject orders without an AHC of exactly 28 characters, for each line item.

Following are guidelines for AHC management:

· EIS permits changing the AHC associated with a service after installation via an Administrative Change Service Order (see EIS contracts Section J.2.4) provided the AHC was not specified on the TO. Although agencies may opt to include the AHC directly in their TOs, this is discouraged as it greatly complicates any future changes an agency may require. If an agency includes AHCs directly in its TOs, any changes to the AHCs requires a TO modification.

· GSA recommends agencies use the AHC structure shown in Figure 3, below, where the first five (5) characters are composed of the Treasury Account Symbol (TAS) and Bureau code and the remaining characters are used to capture any other information the agency requires.

o However, unless otherwise specified in the DPA or other governing authority, the agency may use any desired structure for the AHC provided it is always included and that it is a string of exactly 28 alphanumeric characters on the EIS standard for alphanumeric data fields (see Appendix B.2).

o Agencies should always consider using at least one non-numeric character to prevent automatic type conversion if they intend to import the data into a spreadsheet.

Figure 3 Example of AHC Structure

5.2.2 Agency Service Request Numbers

The Agency Service Request Number (ASRN) is an optional internal government control number that is tracked for all services from order submission through disconnection, if it is provided. Agencies may elect to assign zero, one or two ASRNs to each line item in a given order. The ASRN(s) need not be unique to a single order or line item (i.e., can be duplicated across multiple orders or line items) and may be omitted entirely if the agency so chooses.

The contractor is required to include ASRNs on order notices, inventory, and billing deliverables, if the agency provides them with the order. This data is maintained by the contractor and GSA throughout the lifecycle of the service, making it available for searches from the beginning of service implementation through disconnection.

In defining the ASRN, agencies may use up to 50 characters meeting the EIS standard for alphanumeric fields (see Appendix B.2).

Agencies structure the ASRN depending on their specific needs, such as:

· Track identifiers from agency internal systems

· Sequence orders for accounting purposes

· Identify ordering offices by using standard codes for each

· Track programs, projects, locations, etc.

5.3 Service Ordering

The SO functional requirements and ordering procedures include; the submission of SOs by the agency, receipt of notifications from the contractor at required points in the process, delivery and testing of services by the contractor and service acceptance by the agency.

Only agency OCOs or authorized officials, appointed by the OCO, are allowed to place SOs for EIS services. Agency OCOs with a DPA from GSA, may appoint CORs or other agency officials (consistent with agency rules) to place SOs under a TO and assist with the administration of SOs. The COR, if appointed, is responsible for complying with the terms and conditions of the TO and with any rules, regulations, and conditions promulgated and enforced by its agency.

The contractor will only accept service orders from authorized agency personnel and only for services included in the TO. Any other service orders submitted will result in the order being rejected by the contractor.

After the execution of a TO, by the OCO and the contractor, ordering is done one of two ways:

1. The OCO, or COR acting on behalf of the OCO, issues SOs for services that are within scope and in accordance with the terms and conditions of the TO.

2. The TO, in and of itself, acts as a SO, if it clearly articulates the full details of the delivery requirements and the contractor accepts it as such.

A Service Order (SO) flows from the requirements defined in each TO and provides the contractor with full details of the delivery requirements for the agency-specific services. Multiple SOs may be issued against a single TO.

OCOs, and CORs if authorized by the OCO, can only place SOs after the award of a funded TO. All SOs must be within scope and not exceed the obligated funding on the task order.

For additional detail see EIS contracts Sections G.3 and J.2.4 at http://www.gsa.gov/eis.

5.3.1 Service Order Types

Agencies issue orders that fall into three basic categories:

· for new service installation

· for changes to existing (previously provisioned) services

· for updates or supplements to in-progress orders (not yet provisioned)

Orders and their descriptions for each category are provided in the table below.

Table 1: Orders and Descriptions

Order	Description
Category: New Service Installation
New Service Install	Orders for new services that are not currently being provided by the contractor. New services may require a modification to a task order, or require a new Fair Opportunity (FO) competition and new task order.
Category: Changes to Services Previously Provisioned
Move	Orders that require the removal of an existing service and/or SRE from one location and the re-installation of the identical service and/or SRE at another location. This results in two line items on the SOCN (one to remove the service from the old location and one to add it to at the new location).
Feature Change	Orders that require changes to the features of an existing service but do not require a change in the CLINs for the service. (Features are defined in EIS contracts Section B.)
Configuration Change	Orders that require changes in the configuration of an existing service without adding or removing CLINs or features.
Disconnect	Orders that require the removal of service(s) currently being provided.
Administrative Change	Orders that only require changes to administrative data associated with an existing service. Administrative data is limited to data provided by the government that does not impact service delivery or pricing – for example, AHCs or ASRNs. (Administrative changes are further defined in EIS contracts Section G.3.3.2.2.4.)
Category: Updates/Supplements to In-Progress Orders (prior to SOCN)
Cancel Order	Order updates that cancel the original order in whole or in part. Note: The agency may be liable for a cancellation charge depending on the precise timing of the cancel order as described in EIS contracts Section G.3.3.2.3.1.
Update Service Location	Order updates that change the specified service delivery location from that specified in the original order but do not impact Local Exchange Carrier (LEC) provisioning. Note: Location updates that do impact LEC provisioning are handled as an order cancel and a new order.
Update Features	Order updates that change the specified features of a service from that specified in the original order but that do not require a change in the CLINs for the service. (Features are defined in EIS contracts Section B.) Note: Changes that require new CLINs are handled as a cancel order and a new order.
Update Customer Want Date	Order updates that change the Customer Want Date (CWD) from that specified in the original order. Note: There are specific limitations on changes to the CWD described in EIS contracts Section G.3.3.2.3.4.
Administrative Data Update	Order updates that only change the specified administrative data associated with a service from that specified in the original order. Administrative data is limited to data provided by the government that does not impact service delivery or pricing – for example, AHCs or ASRNs. (Administrative changes are further defined in EIS contracts Section G.3.3.2.2.4.)

5.3.2 Service Order Notifications

As part of the ordering process, the contractor provides a number of notifications to the government. In all cases the contractor must provide these notices to GSA according to the delivery schedule in the table below. An agency may define a different delivery schedule in it’s TO (see EIS contracts Section J.2.4.1.6) otherwise the EIS contracts schedule in the table below is the default.

The delivery of notices to the agency is also at the discretion of the agency and the agency must define and request notification requirements in the TO. If the agency does not request notifications in the TO, there are two options to access the information:

· Via the contractors’ web interface

· GSA Conexus

Table 2: Notifications List – Purpose & Delivery Schedule

Notification	Purpose	Delivery Schedule
Standard Order Notifications
Service Order Acknowledgement (SOA)	Notifies the government its Service Order (SO) has been received.	Within 1 business day after SO receipt date
Service Order Confirmation (SOC)	Notifies the government that the SO information is sufficient to process and has been issued. See also Service Order Rejection Notice.	Within 5 calendar days after SO receipt
Service Order Rejection Notice (SORN)	Notifies the government that the SO information is insufficient or otherwise invalid and that the order cannot be processed. See also Service Order Confirmation.	Within 5 calendar days after SO receipt
Firm Order Commitment Notice (FOCN)	Notifies the government of the Firm Order Commitment (FOC) date when the contractor is committed to delivery of the ordered service.	· If a local access subcontractor is required to complete provisioning: within 1 business day of receiving FOC date from LEC · If a local access subcontractor is not required to complete provisioning: prior to the earlier of 5 days after SOC or 10 days before the FOC date
Service Order Completion Notice (SOCN)	Notifies the government that service has been installed and/or activated (“turned up”). The SO has been completed and billing starts as of the included completion date.	· Within 3 days after service is installed, tested, accepted by the agency
Other Notifications
Service Order Administrative Change (SOAC)	Notifies the government that an administrative change has been completed and provides details of the change.	Within 7 days after Administrative Change SO
Service State Change Notice (SSCN)	Notifies the government that an installed service (defined at the UBI) has changed state (e.g., an auto-sold CLIN has been activated).	Within 24 hours of state change

Table 3: Applicability of Notifications

Orders	Typical Notifications Expected
Standard orders to install or change most services	· SOA · SOC or SORN¹ · FOCN · SOCN
Orders to install or change services subject to Rapid Provisioning	· SOA² · SOCN or SORN¹
Updates/supplements to in-progress orders	· SOA · Possibly SORN¹ · Any notifications submitted against the original/in-progress SO that are no longer correct based on the update are also re-submitted
Administrative data change orders	· SOAC or SORN¹
Activation of an auto-sold CLIN, change in band for band-priced CLINs, or other changes in service state	· SSCN

Notes:

1. In all cases where the SORN is listed as a possibility, the process stops once the SORN is issued and no further notifications are issued against that SO.

2. For rapid provisioning, the SOA may be omitted if the SOCN is issued less than 24 hours after the SO.

5.3.3 Ordering Processes

5.3.3.1 Standard Ordering Process

Standard orders, including installs, moves, changes/updates (excluding administrative change/update orders), and disconnect orders, should follow the process below:

1. The agency initiates a SO with its contractor. Orders are initiated in accordance with EIS contracts and TO requirements. For more information on TOs see the Fair Opportunity and Ordering Guide (FOOG) at http://www.gsa.gov/eistransition.

2. The contractor makes available a Service Order Acknowledgement (SOA) within one business day of the SO receipt date.

3. If the contractor determines that the SO is invalid, it will make available a Service Order Rejection Notice (SORN) within five calendar days of the SO:

a) A SORN submitted by the contractor applies to the entire order (i.e., the contractor may only reject entire orders, not individual line items)

a) In the event of order rejection, the agency may issue a new SO with the corrected information and restart this process

4. If the contractor determines that the SO is valid, it will make available a Service Order Confirmation (SOC) within five calendar days of SO receipt date.

Note: The contractor may choose to split a complex SO into suborders at this point to facilitate efficient order processing. If it does so, the remaining steps in this process will be duplicated for each such suborder.

5. The contractor will make available a Firm Order Commitment Notice (FOCN) indicating its Firm Order Commitment (FOC) date based on the following schedule:

a) If the contractor must obtain local access services, within one business day of receiving the FOC date from the local provider

b) If the contractor does not need to obtain local access service, not later than the earlier of 5 days after SOC, or 10 days before the FOC date

6. Upon completion of the order, the contractor will make available a Service Order Completion Notice (SOCN) within three calendar days of installation and testing.
Note: The TO can change this timeline to be shorter or longer as defined in the EIS contracts Section J.2.4.1.6.

5.3.3.2 Ordering Process for Supplements/Updates

If it is necessary to supplement or update an in-progress service order, the EIS contracts provide specific means of doing so.

Note: Changing data explicitly included in a TO requires a TO modification, and cannot be done via this process (see Section 6.1.1 Task Order Modifications below).

To supplement/update an in-progress service order, the following process is used:

1. The agency places a supplement/update SO with the contractor

2. The contractor provides an SOA in response to the supplement/update SO within one business day unless the applicable order process requires a faster response (e.g. TSP or Rapid Provisioning)

3. If the contractor determines that the supplement/update SO is invalid, the contractor will provide a SORN in response to the supplement/update SO within three calendar days of the supplement/update SO unless the applicable order process requires a faster response (e.g. TSP or Rapid Provisioning)

4. Otherwise, the contractor will update the original order with the new data

5. If any changes are required to notices already provided in response to the original order (e.g., SOC, FOCN), the contractor will provide updated versions of those notices

6. The remainder of the provisioning process will follow the process and timeline associated with the original order (e.g. Standard, TSP, etc.)

5.3.3.3 Administrative Change Ordering Process

According to FAR Part 43, “’Administrative change’ means a unilateral (see FAR 43.103(b)) contract change, in writing, that does not affect the substantive rights of the parties.” If the agency finds it necessary to change administrative data associated with a provisioned service that has completed the provisioning process, the EIS contracts provide specific means of doing so with minimum effort by the agency and the contractor. This process applies only to administrative data, which is defined as data points provided by the agency that have no impact on service delivery or pricing. The following are considered administrative data points provided by the agency:

· Agency Hierarchy Code

· Agency Service Request Number 1

· Agency Service Request Number 2

If the agency places an SO to make an administrative change, the contractor makes the changes requested and provides a Service Order Administrative Change (SOAC) notice within seven (7) calendar days of the SO receipt date. The contractor will not provide any of the other common notices associated with an SO.

5.3.3.4 Auto-Sold Process

Some EIS services include other related CLINs that the contractor automatically bundles with those services. These automatically included CLINs are defined in the EIS contracts Sections B.1.2.11 Auto-Sold CLINs and G.3.3.1.2 Auto-Sold CLINs.

Auto-sold CLINs are included in the SOCN for the associated service but may not be active and accumulating charges until the agency takes some action (e.g., using the feature). In these cases, the activation of the auto-sold CLIN is not considered a separate order and thus is not subject to the order processes. Instead the activation or deactivation of an auto-sold CLIN requires the contractor to notify the agency by submitting a Service State Change Notice (SSCN) as described in the EIS contracts Sections J.2.4.1.10 Service State and J.2.4.2.5 Service State Changes.

5.3.3.5 Rapid Provisioning Process

Certain services, including self-provisioned services, lend themselves to rapid provisioning, which streamlines the provisioning process and reduces the number of order notifications the contractor must provide (see EIS contracts Section G.3.3.3.2, “Rapid Provisioning Orders”). The contractor designates the services that it will offer under the rapid provisioning process. No service may be offered under rapid provisioning unless the contractor commits to provisioning the service within 48 hours of order placement.

The EIS contracts also define the following restrictions the agency should consider in placing its order for these services:

· The order cannot include TSP handling (see Section 5.2.3.7.1 below) or administrative changes (see Section 5.2.3.3 above)

· A Customer Want Date (CWD) is not required and early installation is always allowed

Under rapid provisioning, the contractor only provides the SOA and the SOCN for the order and may omit the SOA as well if the SOCN is submitted within 24 hours of the order.

In addition to designating the services that it will offer under rapid provisioning, the contractor establishes provisioning Key Performance Indicators (KPIs) and SLAs. The contractor may choose to include only a baseline SLA for these services at the contract-level (e.g., 48 hours). The agency should consider specifying minimally acceptable SLAs for these services in it’s TO solicitation as provided for in EIS contracts Section G.8.2 Service Level Agreement Tables. This allows the agency to require SLAs more consistent with commercial practice (e.g., 30 minutes, 4 hours, etc.).

Although the contractor chooses the services it offers under rapid provisioning, the agency may specify in it’s TO solicitation that a service must be offered under rapid provisioning. This may, however, limit the pool of potential offerors that can respond to the agency’s solicitation.

If offered by the contractor as independently orderable CLINs, cloud services and Ethernet Transport Service (ETS) bandwidth-on-demand, must be included under rapid provisioning as further defined below.

5.3.3.5.1 Cloud Services Process

NIST SP 800-145 defines cloud services as Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). These services, if offered by the contractor, typically require an initial setup of umbrella services at the start of the TO which creates the ability for the agency to quickly activate, deactivate, or modify the exact services provided (e.g., increasing the number of virtual machines in use). The initial setup is under ICB provisioning SLA rules (see EIS contracts Section G.8.2.2.2 Individual Case Basis Provisioning SLAs). Within the criteria of rapid and elastic provisioning for cloud services as defined by NIST, the activation, deactivation, and modification of specific services under the umbrella service are subject to the rapid provisioning process if offered as separately orderable CLINs. See also EIS contracts Sections G.8.2.2.2 and G.8.2.2.4.1.

5.3.3.5.2 Ethernet Transport Services Bandwidth-on-Demand Process

Ethernet transport service is described in EIS contracts Section C.2.1.2. The contractor is required to support bandwidth increments and decrements on demand, as agreed between the agency and its contractor. Unless otherwise agreed by the agency and its contractor, on a case-by-case basis, the provisioning time for this feature will meet the EIS contractual SLA of not to exceed 24 hours, measured from the service order to the SOCN.

5.3.3.6 Emergency Ordering Process

If an agency has a need to place an emergency order for a service on the contract, but not on the TO, it can be accommodated two ways under EIS:

1. Modification to existing task orders

2. Exception to Fair Opportunity

The most expeditious route is to modify an existing task order. If the change is not within the scope of the task order, then the OCO must use one of the exceptions to the TO Fair Opportunity detailed in FAR 16.505.

5.3.3.7 DHS OEC Priority Telecommunications Services

The agency’s contractor is required to fully comply and interoperate with all Department of Homeland Security (DHS) Office of Emergency Communications (OEC) Priority Telecommunications Services including TSP, Government Emergency Telecommunications Service (GETS), Wireless Priority Service (WPS), and, when released, Next Generation Network Priority Services (NGN-PS). OEC’s Communications Portfolio Management (CPM) Branch collaborates with the public and private sectors to ensure the National Security Emergency Preparedness (NS/EP) communications community has access to priority telecommunications and restoration services to communicate under all circumstances. For more information on these DHS programs, please visit http://www.dhs.gov.

5.3.3.7.1 Telecommunications Service Priority (TSP) Ordering Process

Agencies should follow the Telecommunications Service Priority (TSP) process found in EIS contracts Section G.11. When an agency submits a TSP order, the standard order process applies except that the contractor follows the prioritizations applicable to TSP orders and defined in Section G.11.3.3. For TSP restoration, the service vendor typically charges a one-time setup fee and a monthly service charge. However, these fees are separate from any charges related to installing or repairing your circuits following an emergency. The TSP pricing structure is detailed in EIS RFP Section B.3, please contact your service provider to learn more about charges.

It is the agency’s responsibility to acquire the TSP codes from the Department of Homeland Security (DHS) Office of Emergency Communications (OEC). TSP Authorization Codes are active for three (3) years, at which point the agency will need to revalidate them. Agencies must request TSP restoration priority before a service outage occurs.

5.3.3.8 Important Ordering Considerations

When placing service orders, the agency should consider the following:

· Configuration: The intended configuration of the service should be determined prior to preparing the service order.

· Order Data: The agency should determine the necessary data elements required for a service prior to placing an order for that service. The contractor cannot accept SOs with missing data elements.

· Data Validation: The contractor is required to validate the data submitted by the agency; however, in the interest of reducing the burden to the contractor and thereby reducing cost, this validation is limited. The contractor performs validation that is common for commercial customers – e.g., location data. The contractor also ensures the presence of critical agency data but not necessarily the accuracy of such data – e.g., the contractor validates that each line on an order has an associated Agency Hierarchy Code (AHC) of the correct length, but does not check that the provided AHC is valid.

· Bulk Orders: Under EIS “bulk orders” are treated identically to any other order for the same services unless specifically included in the TO as a TO Project.

· Expedited Orders: Under EIS there are no provisions for expedited orders other than the TSP process. The agency may elect to include an expedited ordering process in the TO if it so desires. The contractor may impose additional charges for expedited orders.

· Customer Want Date (CWD): Service Orders may include a CWD that indicates the customer’s desired install date. The contractor will make reasonable efforts to accommodate the CWD. If the order includes a CWD, the following requirements apply:

1. Contractors will not issue the SOCN nor begin billing prior to the CWD unless the order specifies that early installation is acceptable.

2. If the agency provides a CWD prior to the defined EIS contracts provisioning interval then the provisioning is best effort and the defined provisioning SLA remains in effect.

3. If the time between the order submission and the CWD is greater than the EIS contracts defined provisioning interval for the service as described in EIS contracts Section G.8.2.2, the service provisioning SLA is waived. However, the TO may specify that the CWD in the SO extends the provisioning interval beyond the normal SLA provisioning interval. In this case, the SLA for that service in the SO cannot be later than the specified CWD.

CWD specifications do not apply to rapid provisioning orders as described in EIS contracts Section G.3.3.3.2.

CWD updates are order updates that change the customer want date from that specified in the original order. If the agency delays the CWD prior to receiving the Firm Order Commitment Notice (FOCN), the contractor will not issue the SOCN and begin billing prior to the new CWD, unless the change requested is less than 14 days before the CWD of the initial order.

5.4 Testing and Accepting Services

Prior to accepting service, the agency’s designated contact will receive an EIS Services Verification Testing Report (EIS Testing Report) from the contractor that shows successful completion of testing as defined in the EIS Services Verification Test Plan, as described in EIS contracts Section E.2.2. The contractor provides the EIS Testing Report, within 3 days of service installation and testing and shows that each service provisioned works properly according to the KPIs defined in EIS contracts Section C.2 , the acceptance criteria defined in the EIS Test Plan and any additional testing defined in the TO. Agencies may have their own additional test and acceptance period and criteria defined in a TO that requires successful completion before accepting services from the contractor.

When the contractor provides the EIS Testing Report then agencies may complete acceptance testing based on the acceptance criteria defined in the EIS Test Plan or as required by the agency in the TO. The acceptance test verifies satisfactory end-to-end service performance and proper operation of all ordered features and functions, as specified in the EIS contracts and TO.

For additional detail on verifying and accepting service please see EIS contracts Section E.2.2.

6 Operations

This section describes the concepts and key functional tasks for EIS operations. The key tasks include, task order administration, billing/dispute processing, SLA management, inventory management, trouble management (service assurance) and program management.

6.1 Task Order Administration

6.1.1 Task Order Modifications

TO modifications may be necessary during the TO period to address requirements or administrative changes. The OCO for each TO will administer the modifications for that TO. The OCO will review modifications that add or change existing services to ensure it is technically sufficient and proposed pricing is fair and reasonable. After determining the contractor’s proposal is acceptable, the OCO and the contractor sign an SF-30, if required. For additional details on TO modifications, see EIS contracts Section J.4.1.

6.1.2 Task Order Close Out

When the EIS contracts term expires, all task orders must be closed out. Each OCO is responsible for closing out task orders in its agency. Close-out is performed according to FAR 4.804.

6.2 Billing and Disputes

6.2.1 EIS Billing Process

The standard billing process is applicable to all TOs. The contractor provides all billing deliverables listed below, via the contractors web interface. By default, all deliverables for the agency are submitted via posting to the contractor's website. If an agency requires a different delivery mechanism (e.g., email) this should be included in its solicitation. GSA Conexus receives the billing deliverables automatically and provides another avenue for agencies to access them.

· On or before the 15^th business day of each month, the contractor provides the following deliverables:

· Billing Invoice (BI)

· Tax Detail (TAX) unless the TO specifies fully-loaded pricing

· Billing Adjustment (BA), if applicable

· Monthly Billing Information Memorandum (to customer only), if required to clarify any line items in the BI

· The contractor also inputs invoice summary data into a designated government system such as WebVendor, Vendor and Customer Self Service (VCSS) system, Invoice Processing Platform (IPP), or other systems as specified in the TO.

· If the agency determines that the BI is valid in its entirety, it will pay the contractor in full, as specified in the contract. Agencies make direct payments to the contractor for their monthly bills just as they do using other GSA contract vehicles (e.g. Schedule 70).

· If the agency determines that the BI is not valid, in whole or in part:

· It will initiate a billing dispute, and

· May withhold payment to the contractor, in whole or in part, as specified in the contract

· The contractor submits a BA if required to correct errors identified after payment.

See EIS contracts Section J.2.5.3.2 for the billing deliverables and supported data exchange details. In addition, Billing Adjustment (BA) and Billing Invoice (BI) deliverable data fields and formats are described in EIS contracts Section J.2.10.2.1.4 and J.2.10.2.1.5 respectively.

6.2.1.1 Billing Summary

Although the contractor will input summary invoice data into a government system to facilitate payment, the BI contains the full detail and is the basis for disputes.

6.2.1.2 Billing Payment

Although EIS includes the right for the government to withhold payment in whole or in part, the details of payment withholding are beyond the scope of this document. The agency is advised to read EIS contracts Section G.4.5 Payment of the Bill by the Government and the other sections referenced therein.

6.2.2 Waived Charges

The BI does not normally include any UBIs without current charges. However, to ensure clarity, an exception is made for specifically waived charges. If a contractor waives a charge that would normally be subject to billing, that UBI will be included in the BI as normal; however, the contractor_charge_waiver_code will be set to Y and the base_line_item_price will be set to zero (0). If the agency finds it beneficial, it may work with the contractor to instead show the normally charged value under base_line_item_price (while keeping contractor_charge_waiver_code set to Y).

Note: The SOCN includes a flag indicating the contractor's intent to waive an NRC: non-recurring_charge_waiver_code. If this data element is reported with a value of Yes for a line item containing an NRC CLIN, Conexus will use this to validate the subsequent BI and will issue a dispute if the charge is not waived. If this value is reported as Yes for a line item containing any non-NRC CLIN, Conexus will ignore the value.

6.2.3 Allowable Taxes

In support of the EIS contracts, GSA has analyzed various telecommunications-related taxes across the country and determined those that might legally apply to services under EIS. This information is provided to the EIS contractors as the Allowable Taxes reference table (ALLTAX) as described in EIS contract J.2.10.2.2.10. EIS contractors are not permitted to bill an agency for any taxes not included in the ALLTAX reference file. The specific taxes billed are captured in the Tax Detail (TAX) deliverable and can also be reviewed via GSA Conexus.

As the inclusion of a non-allowed tax has interrelated effects across the billing process, GSA recommends that agencies dispute and withhold payment on any BI line item that includes such taxes.

6.2.4 Billing Accuracy

The EIS contract includes defined Key Performance Indicators (KPIs) for the accuracy of both the data content and the charges included in a BI (see EIS contract Section G.4.12).

6.2.4.1 Billing Charges Accuracy (BCA)

EIS contract Section G.4.12.2 defines the Billing Charges Accuracy (BCA) KPI as a measure of the accuracy of the charges submitted in the BI deliverable and provides a calculation showing a comparison between the charge submitted on each line and the calculated, correct charge for that line. The charges being compared here are the values found in the data element line_net_amount. The line_net_amount, in turn, is the sum of:

· total_line_item_amount (the total charge for the service itself)

· agf_amount (the calculated AGF, based on total_line_item_amount)

· billed_aggregated_tax (the sum of the associated taxes in the Tax Detail file)

An error in calculating any of these three values will result in an erroneous line_net_amount and therefore factor negatively in calculating the BCA. By extension, if any of the associated detailed taxes are incorrectly calculated or not allowed, the billed_aggregated_tax will be incorrect and thus the line_net_amount will be incorrect.

6.2.4.2 Billing Level & Billing Accuracy

EIS contract Section J.2.5.1.8 allows the agency, in the TO, to specify a billing level other than the standard TO-level. If this option is used, there are implications for measuring and reporting the Billing Accuracy SLA as the underlying KPIs are required to be measured per BI submission (EIS contract Sections G.4.12.1 and G.4.12.2) while the SLA, if failed, is credited at the TO-level (EIS contract Section G.8.2.3).

Multiple TOs per BI: When reporting the billing accuracy KPIs, Billing Data Accuracy (BDA) and Billing Charges Accuracy (BCA), for BIs that cover multiple TOs, the EIS contractor must report the KPI results on the SLA Report (SLAR) for each TO. Similarly, if the Acceptable Quality Level (AQL) standards are not met on a given multi-TO BI, the EIS supplier must issue credits against all associated TOs.

Multiple BIs per TO: When reporting the billing accuracy KPIs in cases where a single TO is billed using multiple BIs, the EIS contractor must report the KPI results for each BI on the TO SLAR—e.g., if the TO is billed on three BIs, the TO SLAR will have three sets of KPI results for billing accuracy. If any of the KPI results fails to meet the AQL standard, the EIS contractor must issue a credit based on the entire TO.

6.2.5 Disputes

The EIS contracts include a dispute handling process that provides customer agencies the requirements they need to ensure they remain in control of the agency-contractor relationship (for more information see EIS contracts Section G.4.4 Disputes). The requirements include:

1. Disputes can result from Billing, SLA Credit Requests, or Inventory Reconciliation

2. The contractor will provide a monthly Dispute Report with the current status of each opened dispute

3. The dispute resolution timeline is standardized at 180 days

Figure 4 Sources of Disputes under EIS

6.2.5.1 Billing Disputes

Under EIS the contractor makes available to the agency a detailed Billing Invoice (BI) on a monthly basis. While many small concerns can easily be resolved via a simple request for clarification, others will require a formal process. The OCO, or authorized ordering official may submit to the contractor a dispute notice as defined in EIS contracts Section J.2.6 Disputes. Disputes will be resolved in accordance with the procedures and requirements of Section G.4.4 and J.2.6. In accordance with G.4.4 the contractor is required to resolve all disputes within 180 days of the dispute notice and the government reserves the right not to make payment for disputes that are not resolved within 180 days.

Agencies may contact GSA customer support for assistance with disputes.

6.2.5.2 SLA Credit Request Disputes

Under EIS the contractor must respond to any customer SLA Credit Request (SLACR) within 30 days of issuance. If the contractor rejects the request, the customer may review the contractor’s explanation and if it is inadequate or incorrect, the customer may open a dispute based on the SLACR Response. SLA Credit Request disputes will be resolved in accordance with the procedures and requirements of Section G.4.4. and J.2.6.

6.2.5.3 Inventory Disputes

Under EIS the contractor must make available to the agency a detailed Inventory Reconciliation (IR) on a monthly basis. This deliverable can be used to validate the reported inventory against the expected inventory based on Service Order Completion Notices (SOCNs). It is expected that most discrepancies will be easily resolved via requests for clarification or through the standard inventory reconciliation process as described in the EIS contracts Section G.7; however, in the event that an issue proves irresolvable via those methods, EIS provides the option for the agency to open a dispute based on inventory disparities. Inventory Reconciliation (IR) disputes will be resolved in accordance with the procedures and requirements of Section G.4.4 and J.2.6.

6.2.5.4 EIS Dispute Handling Process

Regardless of the source of the dispute, the overall dispute process is the same as described in the EIS contracts Sections G.4.4 and J.2.6:

1. The agency identifies an area of dispute

2. The agency issues the dispute to the contractor

3. The contractor reviews the dispute

4. If the contractor agrees with the agency’s finding, it responds with concurrence and the dispute is resolved

5. If the contractor does not agree with the agency’s finding, the agency and contractor work together to reach a resolution to the dispute

6. If the agency and contractor cannot reach an acceptable resolution, the dispute is escalated to the agency OCO

7. Once the dispute is resolved, the contractor submits an updated deliverable as required

8. If a billing dispute is not resolved within 180 days, the government reserves the right not to make payment

Note: The dispute file has a rigidly-defined format. The dispute file must be submitted to the contractor as a table in CSV format with columns that match those found in EIS contract Section J.2.10.2.1.9 exactly. Additionally, the agency must correctly format each data element as further defined in EIS contract Section J.2.10.3.1. Failure to do so may result in delays in processing the dispute.

To track and report on the dispute process described above the contractor is required to make available to the agency a monthly Dispute Report (DR) by the 15^th business day of each month. This report captures the current status of each opened dispute.

The figure below depicts the EIS Dispute Handling Process.

Figure 5 EIS Dispute Handling Process

6.2.5.5 Common Dispute Situations

Billing Disputes:

· Incorrect CLIN price

· Incorrect quantity

· Item doesn’t match or never shown on the SOCN

· Duplicate charge

· Incorrect tax charge, fees, and surcharges

· Usage charge doesn’t match or never reported on SSCN

· Billing beyond service disconnection

· Back bill beyond 90 days

· Billing before CWD without approval for early installation

· Incorrect proration calculation

· Incorrect rounding calculation

· Other invalid data value

Inventory Disputes

· Data on IR does not match SOCNs

· Incorrect inclusion of auto-sold CLIN

· Other invalid data value

SLA Credit Disputes

· Contractor rejects SLA credit request (SLACR) due to:

o Disagreement over SLA requirement

o Disagreement over SLA results

o Disagreement over mitigating circumstances (e.g. government caused delay)

6.3 Service Level Management

The EIS contracts Section G.8 describe the requirements for Service Level Management. The contractor is required to provide SLA related deliverables as specified in the EIS contracts Section J.2.8.2 to both agency customers and GSA Conexus. The contractor is required to make available a Service Level Agreement Report (SLAR), which captures performance on all applicable SLAs and associated KPIs, monthly, NLT the 15th day of the month. GSA’s Office of Telecommunications Services (OTS) will provide support to the agency in SLA credit processing that is further described in Section 6.3.4.

The contractor is required to maintain services at an Acceptable Quality Level (AQL) for each associated Key Performance Indicator (KPI). Section C of the EIS contracts specifies the applicable KPIs for each service offered. These KPIs fall in two categories: Service-Specific and Incident-Based.

Service-Specific KPIs measure the general quality of service provided and include such items as latency and availability. These KPIs are measured for each uniquely installed instance of a service on a monthly basis. Failure to maintain the specified AQL for all specified KPIs for a given service installation constitutes failure to meet the service-specific SLA for that service installation and obligates the contractor to pay the associated credits as defined in EIS contracts Section G.8.2.1.1.2. A list of all service-specific KPIs and their associated references in EIS contracts Section C is included in Appendix D of this Handbook.

Incident-Based KPIs measure the time-to-restore (TTR) for any service outages. These KPIs are measured for each outage and reported monthly. Failure to meet the specified AQL for the TTR after an outage constitutes failure to meet the TTR SLA for that incident and obligates the contractor to pay the associated credits as defined in EIS contracts Section G.8.2.1.2.2. A list of services with associated Incident-Based SLAs, and their associated references in the EIS contracts Section C is included in Appendix D of this Handbook.

6.3.1 Standard Provisioning SLAs

The contractor is required to complete orders within the provisioning intervals defined in the table below and in EIS contracts Section G.8.2.2.1.1. Failure to complete the provisioning of the service within the timeframes constitutes a failure to meet the SLA for that provisioning incident.

Table 4: Standard Provisioning SLAs

Standard Provisioning Services	Orders SLA (Calendar Days)
Disconnect (all services)	30
Circuit Switched Data Service (CSDS)	23
Toll-Free Service (TFS)	45
Private Line Service (PLS):
PLS ≤ DS1	45
DS1 < PLS ≤ DS3	85
DS3 < PLS ≤ OC3	120
VPN Service (VPNS)	45

For orders with non-CONUS delivery locations, these services have ICB provisioning intervals and follow the requirements described below for Individual Case Basis Provisioning SLAs.

6.3.2 Individual Case Basis Provisioning SLAs

Certain services do not have predefined provisioning intervals (see the table below for a complete list). For these services, the performance objective is defined on an ICB with the required delivery schedule established in the TO. Failure to complete the provisioning of service within the timeframe specified in the TO constitutes a failure to meet the SLA for that provisioning incident.

Special considerations:

1. For Ethernet Transport Services, see also EIS contracts Section G.8.2.2.4.2 Bandwidth-on-Demand.

2. For Cloud Services; including IaaS, PaaS, SaaS, and CDNS; the ICB provisioning interval must be no greater than the provisioning interval proposed as specified in EIS contracts Section G.8.2.2.4.

3. For any services proposed under rapid provisioning that also appear on this list, the ICB provisioning intervals must be no greater than the provisioning interval proposed as specified in EIS contracts Section G.8.2.2.4.

Table 5: Services Subject to ICB Provisioning Intervals

ICB Provisioning Services
Audio Conferencing Service (ACS) Cloud Infrastructure as a Service (IaaS) Cloud Platform as a Service (PaaS) Cloud Software as a Service (SaaS) Cloud Content Delivery Network Service (CDNS) Co-located Hosting Service (CHS) Commercial Satellite Communications Services Commercial Mobile Satellite Service(CMSS) Commercial Fixed Satellite Service (CFSS) Contact Center Service (CCS) Dark Fiber Service (DFS) Ethernet Transport Service (ETS) Internet Protocol Service (IPS) Managed Network Service (MNS) Managed Security Service (MSS) Managed Trusted Internet Protocol Service (MTIPS) Managed Mobility Service (MMS) Optical Wavelength Service (OWS) Unified Communications Service (UCS) Video Teleconferencing Service (VTS) Voice Services (IPVS, CSVS) Web Conferencing Service (WCS)

ICB Provisioning Services

Audio Conferencing Service (ACS)
Cloud Infrastructure as a Service (IaaS)
Cloud Platform as a Service (PaaS)
Cloud Software as a Service (SaaS)
Cloud Content Delivery Network Service (CDNS)
Co-located Hosting Service (CHS)
Commercial Satellite Communications Services

Commercial Mobile Satellite Service(CMSS)
Commercial Fixed Satellite Service (CFSS)

Contact Center Service (CCS)
Dark Fiber Service (DFS)
Ethernet Transport Service (ETS)
Internet Protocol Service (IPS)
Managed Network Service (MNS)
Managed Security Service (MSS)
Managed Trusted Internet Protocol Service (MTIPS)
Managed Mobility Service (MMS)
Optical Wavelength Service (OWS)
Unified Communications Service (UCS)
Video Teleconferencing Service (VTS)
Voice Services (IPVS, CSVS)
Web Conferencing Service (WCS)

6.3.3 SLA Credit Processing

The government must issue a credit request (SLACR) within six (6) months of the original SLA failure. The contractor is required to review such requests and respond within 30 days by submitting a SLACR response. The contractor must issue the credit within two billing cycles of the SLACR response unless it chooses to reject the request. The contractor works with the government to resolve any disputes and agree on an appropriate credit award in accordance with the dispute process, EIS contracts Section G.4.4. The agency may specify additional credit management requirements in its Task Order.

Note: The SLACR file has a rigidly-defined format. The SLACR must be submitted to the contractor as a table in CSV format with columns that match those found in EIS contract Section J.2.10.2.1.22 exactly. Additionally, the agency must correctly format each data element as further defined in EIS contract Section J.2.10.3.1. Failure to do so may result in delays in processing the request. See also Section 6.3.4 for support available to the agency in this process.

EIS contracts Section G.8.4 describe the SLA Credit Management Methodology in detail.

6.3.4 SLA Credit Processing Support Services

GSA’s Office of Telecommunications Services (OTS) will provide support to the agency in SLA credit processing. These support services are covered by the Associated Government Fee (AGF) agencies pay to GSA.

The OTS will provide support for the following key activities:

· Verification and validation of SLA reports and credit computation

· Verification and validation of each SLA Credit Request (SLACR) form

· Review and coordinate finalization of SLACR form based on agency feedback

· Provide administrative support [status tracking] with contractors to ensure that credits are processed successfully

· SLA credit related disputes with contractors

6.4 Inventory Management

The contractor must establish and maintain a complete and accurate inventory of EIS services provided to agencies. The agency is responsible for the accuracy of its inventory and reconciling discrepancies with the contractor(s). Since reconciliation can be complex, agencies should regularly review contractor’s inventory files and reconcile records between themselves and the contractor. The agency will have access to the contractor’s secure web interface that allows the agency to make queries, obtain reports and perform periodic downloads as needed for audits, billing verification, and other government program management purposes.

EIS contracts Section J.2.10.2.1.12, Inventory Reconciliation, identifies the inventory data elements required by service as part of the Inventory Reconciliation (IR) deliverable.

The key tasks associated with inventory management are defined below:

1. The agency audits the EIS inventory data provided by its contractor and advises the contractor of discrepancies noted in the EIS inventory data.

2. When the agency advises its contractor of inventory data discrepancies, the contractor will investigate the discrepancies reported and work with the agency to resolve them.

3. The contractor will update the agency’s inventory current view to reflect all additions, deletions, or changes to the EIS services being provided within one (1) business day of the issuance of the SOCN for every addition, deletion, or change.

6.4.1 EIS Inventory Data Discrepancies

EIS inventory data discrepancies reported by the agency will be investigated by the contractor. If the contractor agrees to a correction, the data discrepancies are corrected within ten (10) days.

If the contractor does not agree to a correction, it will advise the agency and work with the agency to resolve the issue.
If the discrepancy is escalated to the OCO for resolution, the agency and the contractor will work with the OCO to resolve the issue to the agency’s satisfaction.

If the EIS inventory data elements in the SOCN issued to the agency were in error, the contractor will issue, at no additional cost to the agency, a corrected SOCN or a new correct SOCN that clearly references the original error.
If the EIS inventory data elements result in a billing error in the Billing Detail (BD) deliverable issued to the agency, the contractor will issue, at no additional cost to the agency, a Billing Adjustment (BA) deliverable.
The contractor shall provide a monthly IR deliverable as defined in EIS contracts Section J.2.7.

6.5 Trouble Management (Service Assurance)

Agencies can open and review trouble tickets for any troubles reported or discovered. Contractors are required to create trouble tickets requested by an agency, provide status updates, provide online real-time access to trouble ticketing and system status information, update open trouble tickets and escalate as needed, and report the resolution to the initiator.

Contractors establish and implement procedures and systems for 24x7x365 trouble ticket and complaint collection, entry, tracking, analysis, priority classification, and escalation for all services to ensure that problems are resolved within the timeframes specified in the EIS contracts Section G.8 Service Level Management.

As the first priority, the contractor will restore any TSP restoration coded service, as quickly as possible, using best effort.

Agencies can escalate at any time using the escalation path provided by their contractor. The contractor will escalate issues according to its Program Management Plan (PMP).

6.5.1 Trouble Ticket Management (Reporting Information)

The agency will receive from the contractor the capability to query, sort, export, and save in formats such as PDF/CSV or standard/structured file formats, trouble and complaint records by any field or combination of formatted (that is, not free-form text) fields in each record.

The contractor will process any credits applicable to the service outage based on this record of information.

6.5.2 Trouble Ticket Management (Deliverables)

The contractor will provided the following reports within 14 days after the end of each fiscal year quarter. Unless otherwise specified by the agency’s TO, the contractor may use its standard commercial report format for these reports provided that it contains the information specified.

· Trouble Management Performance Summary Report – summarizes the number of trouble reports opened and resolved during the reporting period.

· Trouble Management Incident Performance Report - describes each trouble report issued during the reporting period by contractor trouble report number, agency and AHC, UBI, time opened and time resolved.

6.6 Program Management Functions

6.6.1 Contractor Program Management Functions

Contractors are required to provide the following program management functions to agencies including but not limited to:

· Program Control

· Planning at the Program Level

· Planning at the Agency Level

· Contractor Performance

· Resource Management

· Revenue Management

· Reporting and Reviews

· Senior-level Communications

7 Support Resources

7.1 Contractor System

Agencies will use the contractor’s Business Support System (BSS) as defined by the OCO for ordering and inventory management. Access procedures for the contractor’s BSS are defined by the contractor and will be available on its website. A list of contractor websites is available on the GSA website at http://www.gsa.gov/eis.

7.2 GSA Systems

GSA Systems are secure government systems used for contract management and pricing. These systems allow contractors to provide TO and contract related data. Agencies may use GSA Systems’ Pricer tools for price analysis and planning. For additional detail please see Network Hosting Center (NHC) at http://www.gsa.gov/eis.

7.3 GSA Conexus

GSA Conexus provides a secure site with a single sign-on allowing registered agencies to access EIS contracts and agency-specific data. Conexus is GSA's new platform that will support EIS acquisition related activities. Agency’s access to GSA Conexus is restricted to authorized personnel. Agencies are able to do the following:

· Manage funding

· Place and track service orders

· Maintain accurate inventories

· Perform billing reconciliations

· Review recommended disputes

· Obtain reporting analytics

· Deliverable review and monitoring

· Discrepancy Detection

· Dispute and SLA Credit Request (SLACR) review

· Aging Reports

· Agencies may also login and download the SLA reports from GSA Conexus

For additional detail please see GSA Conexus Help Guide at https://conexus.gsa.gov.

Appendix A Proration Formula

This Proration Formula is intended to increase agency flexibility regarding how proration is calculated. In reviewing proration approaches, it was determined that agencies have varying goals that cannot all be met by a single proration method:

Many agencies are primarily concerned with keeping direct service costs at a minimum
Some agencies place a higher priority in being able to have stability in the actual charges assessed for each day of service regardless of the month that prorated charges occur

The first set of agencies would be best served by using a proration formula that calculates daily charges based on the actual number of days in the month (‘Month-Length Proration’).

The second set of agencies would be best served by using a proration formula that calculates the daily charge based on a ‘normalized’ month with 30 days (‘Normalized 30-Day Month Proration’).

For details on the proration formulas for both Month-Length Proration and Normalized 30-Day Proration see EIS contracts Section J.2.5.1.5.1 at http://www.gsa.gov/eis.

Agencies can choose either proration formula in their TO. The contractor will respond to the TO solicitation and indicate if it supports the requested proration formula. Contractors are required to support at least one of the formulas. The contractor may add support for a previously unsupported proration type at any time without contract modification by following the BSS Change Control process in Section G.5.5.1. The contractor shall complete successful retesting of the BSS test cases associated with proration prior to billing.

Month-Length Proration

Description

· The daily charge for prorated line items is the Monthly Recurring Charge (MRC) divided by the actual number of days in the billing month

[MRC / number_of_days]

Advantages

· Standard commercial practice

· Relatively easy to implement

Disadvantages

· Daily charge varies by month length for all prorated charges

Adjusted Normalized 30-Day Month Proration

Description

· The daily charge for prorated line items is the MRC divided by a
normalized 30 day month [MRC / 30]

· Additional rules are then applied in limited cases to adjust the
charged days if the service was in place the entire billing month and
the billing month has more or less than 30 days

Advantages

· No variance with Month-Length approach for price changes

· Consistent daily charges for Installs and Disconnects (no price changes)

Disadvantages

· Daily charge varies by month for price changes

Appendix B Management and Operations – Contractor Deliverables

The following table provides a list of contractor deliverables relating to the MOPS functions of Ordering, Billing, Inventory, SLA Management, Disputes, and Trouble Ticket Management. Refer to the EIS contracts Section F for full details of all contractor deliverables.

Table B-1: Contractor Deliverables for Management and Operations

#	Contract Reference	Name	Frequency	Available To
Function: Ordering
1.	J.2.4.2 J.2.10.2.1.16	Service Order Acknowledgement (SOA)	NLT one (1) business day after Service Order (SO)	GSA Conexus and agency COR
2.	J.2.4.2 J.2.10.2.1.20	Service Order Rejection Notice (SORN)	NLT 5 days after SO	GSA Conexus and agency COR
3.	J.2.4.2 J.2.10.2.1.19	Service Order Confirmation (SOC)	NLT 5 days after SO	GSA Conexus and agency COR
4.	J.2.4.2 J.2.10.2.1.11	Firm Order Commitment Notice (FOCN)	Local access subcontractor required: · Within one (1) business day of receiving FOC date Local access subcontractor not required: NLT the earlier of: · 5 days after SOC, or · 10 days before the FOC date	GSA Conexus and agency COR
5.	J.2.4.2 J.2.10.2.1.18	Service Order Completion Notice (SOCN)	NLT 3 days after service is installed and tested	GSA Conexus and agency COR
6.	J.2.4.2 J.2.10.2.1.17	Service Order Administrative Change (SOAC)	NLT 7 days after Administrative Change Order	GSA Conexus and agency COR
7.	J.2.4.2 J.2.10.2.1.21	Service State Change Notice (SSCN)	Within 24 hours of state change	GSA Conexus and agency COR
Function: Billing
8.	J.2.5.2 J.2.10.2.1.5	Billing Invoice (BI)	Monthly, NLT 15^th business day	GSA Conexus and agency COR
9.	J.2.5.2 J.2.10.2.1.24	Tax Detail (TAX)	Monthly, NLT 15^th business day	GSA Conexus and agency COR
10.	J.2.5.2 J.2.10.2.1.13	Monthly Billing Information Memorandum	Monthly, NLT 15^th business day (as needed)	Agency COR
11.	J.2.5.2 J.2.6.2 J.2.8.2 J.2.10.2.1.4	Billing Adjustment (BA)	Monthly, NLT 15^th business day (as needed)	GSA Conexus and agency COR
Function: Disputes
12.	J.2.6.2 J.2.10.2.1.10	Dispute Report (DR)	Monthly, NLT 15^th business day (as needed)	GSA Conexus and agency COR
Function: Inventory
13.	J.2.7.2 J.2.10.2.1.12	Inventory Reconciliation (IR)	Monthly, NLT 15^th day of month	GSA Conexus
Function: SLA Management
14.	J.2.8.2 J.2.10.2.1.14	Service Level Agreement Report (SLAR)	Monthly, NLT 15^th day of month	GSA Conexus, OCO and agency COR
15.	J.2.8.2 J.2.10.2.1.22	SLA Credit Request Response	Within 30 days of SLA Credit Request	OCO and agency COR
Function: Trouble Ticket Management
16.	J.2.8.2 J.2.10.2.1.25	Trouble Management Performance Summary Report	Quarterly, NLT 15 days after the end of the FY quarter	Agency COR
17.	J.2.8.2 J.2.10.2.1.24	Trouble Management Incident Performance Report	Quarterly, NLT 15 days after the end of the FY quarter	Agency COR

B.1 Data Transfer Mechanism & Format

By default, all management and operations deliverables for the agency are submitted via posting to the contractor's website (see Appendix B.1.3, below). If an agency requires a different delivery mechanism (including email) this should be specified in its solicitation. Similarly, if the agency requires a deliverable that is delivered only to GSA Conexus, the agency must include this requirement in its TO.

B.1.1 XML over Web Services

Under EIS, all order notifications (Table B-1, items 1 through 7) are submitted to GSA Conexus in Extensible Markup Language (XML) over web services. Web services should not be confused with the contractor’s website or portal. See Appendix B.1.3. This data is formatted to facilitate automated processing and is not generally suitable for direct consumption by agency personnel.

Note: This format is not, by default, provided to the agency.

B.1.2 PSV over SFTP

The EIS contract requires the submission of the BI, TAX, BA, DR, IR, and SLAR (Table B-1, items 8, 9, 11, 12, 13, & 14 respectively) to GSA Conexus to be via Pipe Separated Value (PSV) over Secure File Transfer Protocol (SFTP). Although intended to facilitate automated processing, the PSV format is very similar to Comma Separated Value (CSV) and can be readily imported into Excel for manipulation by agency personnel (import as delimited text and specify the pipe “|” as the delimiter).

Note: This format is not, by default, provided to the agency.

B.1.3 Human-Readable via Web Interface

As noted above, the default “submission” mechanism for management and operations deliverables provided to the agency is to make them accessible via the contractor’s web interface. EIS contract Section G.5.3.1 defines the functionality and technical requirements including accessibility via standard web browsers without special plug-ins or extensions and compliance with Section 508 of the Rehabilitation Act. In addition, nearly all of the management and operations deliverables listed in table B-1 are made available via the web interface (the SLA Credit Request Response and the two Trouble Management reports are the exceptions).

Note: This is the default delivery mechanism for the agency. Any other mechanisms must be specified in the TO.

B.1.4 Human-Readable via Email

In nearly all cases, the EIS contract permits the agency to request any management and operations deliverable be submitted via email. In addition, there are four such deliverables that are submitted to the agency via email by default:

· Monthly Billing Information Memorandum (Table B-1, item 10)

· SLA Credit Request Response (Table B-1, item 15)

· Trouble Management Performance Summary Report (Table B-1, item 16)

· Trouble Management Incident Performance Report (Table B-1, item 17)

EIS contract Section J.2.9.4 specifies several requirements the contractor must adhere to when submitting via email:

1. Use body text only for brief information (not to exceed 150 words).

2. Use attachments for longer data sets or for structured data.

3. Use attachment formats that are compatible with one of the following.

a) Microsoft Office (current version and two most recent prior versions)

b) Portable Document Format (PDF)

c) Other formats as approved in writing by the relevant CO or OCO

4. Encrypt attachments if required by the TO or the relevant CO or OCO

5. Include appropriate contract and TO identification information in the body and all attachments

6. Submit directly to the Point of Contact (POC) specified by the OCO

Note: This mechanism is available for most deliverables but is not the default (except where noted above). If the agency requires email submission, this must be captured in the TO.

B.1.5 Other Mechanisms & Formats

In most cases, the EIS contract allows for the submission via other mechanisms and in other formats for deliverables going directly to the agency. In all such cases, the agency must include those requirements in the solicitation and TO.

Note: See also Appendix B.4 Alternative Deliverable Requirements

B.2 Data Content Types

Each data element or field in each management and operations deliverable has a pre-defined data type specified in EIS contract Section J.2.10.3.1.2.

· Alpha

o Characters in the standard English alphabet (A-Z and a-z)

o Excludes numbers and special characters (punctuation, symbols, etc.) unless required as part of the edit mask or element specifications in EIS contract Section J.2.10.1.1

· Alphanumeric

o Characters on the standard 104-key US qwerty keyboard excluding the pipe, ‘|’, character

o Note: see important information in Appendix B.2.1

· BLOB:

o Binary Large Object

o Used for attachments (see EIS contract Section J.2.9, especially Section J.2.9.2.2)

· Numeric

o Numbers (0-9) and at most one decimal point ‘.’

o Negative values are preceded by a minus sign ‘-’

o Percentages are always converted to standard decimal values, e.g., 5% is presented as ‘0.05’

· Date

o Full date value including 4-digit year, 2-digit month, and 2-digit day

o Example: 2015-01-01

· Time

o Full time value based on 24-hour clock including 2-digit hour, 2-digit minute, 2-digit second and offset from UTC in hours and minutes

o Example: 13:05:30-04:00

· Date/Time

o Full date and time value joining the date and time (as described above) separated by an upper case ‘T’

o Example: 2015-01-01T13:05:30-04:00

B.2.1 Prohibited Characters in Web Services

As noted above, the EIS contract defines alphanumeric as "characters on the standard 104-key US qwerty keyboard excluding the pipe, ‘|’, character". With the exception of the UBI, which also restricts the use of underscore, ‘_’, this definition provides general requirements for those data elements specified as alphanumeric. However, when data is submitted via web services, the contractor must also adhere to the requirements specified in EIS contract Section J.2.10.1.3.3 which require the submission to be in accordance with the XSDs and WSDLs attached within that section. Please note that those documents prohibit the use of the caret, ‘^’, in any web services call.

As a practical matter, the agency should avoid using the caret or pipe in any data it provides to the contractor as the contractor will likely be forced to reject the data to remain in compliance with the EIS contract.

B.3 Detailed Considerations

In addition to the general information on management and operations deliverables, there are specific contractual factors that the agency should consider in preparing solicitations and planning TO management.

B.3.1 Capturing Phone Numbers in the SOCN, BI, and IR

Certain services have inherently linked phone numbers. These include Internet Protocol Voice Service (IPVS), Circuit Switched Voice Service (CSVS) as well as wireless services. For all such services where a phone number is inherently linked to the service, the data element phone_number_toll_free_and_700_number is applicable and thus must be reported on the SOCN. However, as these services are often ordered in bulk, there are two possible approaches:

1. Assign a separate UBI to each phone line

2. Assign a single UBI to the service and repeat that UBI for each phone number

While the first approach is preferred, an EIS contractor may use either approach unless otherwise specified in the TO. Note that the approach used in the SOCN will dictate the approach used in the BI and IR.

While the choice of approach is generally left to the contractor to decide, the agency may specify one method or the other in the TO although doing so may remove some contractors from consideration and/or may result in higher costs to the agency. Whether the method is specified in the TO or left to the contractor, the choice will impact the agency’s management of the service; it is, therefore, important that the implications be fully understood.

Assigning a Separate UBI for each Phone Line

Under this approach, the SOCN captures each phone number as a separate entry using a different UBI for each. For example, assuming the service is IPVS and five lines are provisioned, the SOCN would capture the phone number and quantity as shown below:

UBI	Phone #	Quantity
ipvsL5_p001	5555555551	1
ipvsL5_p002	5555555552	1
ipvsL5_p003	5555555553	1
ipvsL5_p004	5555555554	1
ipvsL5_p005	5555555555	1

Under this approach, future changes to the service such as adding or removing lines need only reference the impacted UBIs.

Assigning a Single UBI for the Service as a Whole

Under this approach, the SOCN captures each phone number as a separate entry using the same UBI for each. For example, assuming the service is IPVS and five lines are provisioned, the SOCN would capture the phone number and quantity as shown below:

UBI	Phone #	Quantity
ipvsL5_n001	5555555551	1
ipvsL5_n001	5555555552	1
ipvsL5_n001	5555555553	1
ipvsL5_n001	5555555554	1
ipvsL5_n001	5555555555	1

Under this approach, future changes to the service, such as adding or removing lines, must fully reference all lines. For example, if the line associated with phone number 5555555553 is to be removed, the SOCN would capture the phone number, quantity, and change data as shown below:

Header Order Type:		Change

UBI	Phone #	Quantity	Line Item Order Type
ipvsL5_n001	5555555551	1	None
ipvsL5_n001	5555555552	1	None
ipvsL5_n001	5555555553	1	Remove
ipvsL5_n001	5555555554	1	None
ipvsL5_n001	5555555555	1	None

Similarly, adding a new line with phone number 5555555556 would require a SOCN to capture the phone number, quantity, and change data as shown below:

Header Order Type:		Change

UBI	Phone #	Quantity	Line Item Order Type
ipvsL5_n001	5555555551	1	None
ipvsL5_n001	5555555552	1	None
ipvsL5_n001	5555555553	1	None
ipvsL5_n001	5555555554	1	None
ipvsL5_n001	5555555555	1	None
ipvsL5_n001	5555555556	1	Add

B.4 Alternative Deliverable Requirements

The EIS contract specifies the frequency and required delivery times for all contractor deliverables (see EIS contract Section F.2). In general, an agency may not change these requirements with the exception of the Service Order Completion Notice (SOCN). Although EIS contract Section J.2.4.2.1, item 9, allows an agency flexibility to change a SOCN delivery time, it is critical that agencies understand and remain aware that changing a delivery date does not impact the billing start date or the billing end date (for disconnects). Per EIS contract Section G.4.1.2, the billing start and end date is controlled by the order completion date which is a data element within the SOCN. Also, please note that changes to the SOCN delivery time will not allow GSA Conexus to accurately verify and validate the delivery of SOCNs.

Similarly, the EIS contract specifies detailed format, content, and transfer mechanism requirements for most contractor deliverables while allowing the agency to also have alternative requirements (see EIS contract Section J.2.2.3). However, in this case the EIS contract distinguishes between contractor deliverables submitted to GSA Conexus and those submitted to the agency. Contractor deliverables submitted to GSA Conexus must comply with the requirements in EIS contract Section J.2. Any changes to contractor deliverables submitted to the agency that are not aligned to those requirements will not be reflected in contractor deliverables submitted to GSA Conexus. This may result in GSA Conexus having data that differs from the data provided to the agency and will negatively impact the ability of GSA Conexus to provide verification and validation support to the agency.

Appendix C Management and Operations – Options Specified in the Task Order

Following is a list of options relating to MOPS requirements that may be specified in the Task Order. EIS contracts Section G and Section J.2 provides details of all optional requirements.

#	MOPS Function	Description	Contract Section Reference
1.	Ordering	Order Notifications Deliverables: · Service Order Acknowledgement (SOA) · Service Order Confirmation (SOC) · Firm Order Commitment Notice (FOCN) · Service Order Completion Notice (SOCN) · Service Order Rejection Notice (SORN) · Service Order Administrative Change (SOAC) · Service State Change Notice (SSCN)	J.2.4.3.2 J.2.10.2.1.16 J.2.10.2.1.19 J.2.10.2.1.11 J.2.10.2.1.18 J.2.10.2.1.20 J.2.10.2.1.17 J.2.10.2.1.21
2.		Agency Hierarchy Code (AHCs); Agency Service Request Number (ASRN)	G.3.3.1.1, J.2.4.1.2 G.4.1.6, J.2.4.1.4
3.		Customer Want Date for Services on the Task Order	G.3.3.1.3
4.		Task Order Project: Specify as a TO requirement that TO is to be managed as a Task Order Project	G.3.3.3.3
5.		TSP Orders	G.3.3.3.1, J.2.4.2.2
6.		Administrative Setup: OCO/CORs Information	G.2.2
7.	Billing	Selection of system for delivery of Electronic Billing: Web Vendor/VPSS/IPP/Other	G.4.1.7
8.		Proration Type – Month Length vs Normalized 30 day month	J.2.5.1.5
9.		Billing deliverables- · Billing Invoice (BI) · Billing Adjustment (BA) · Tax Details (TAX)	J.2.5.3.2, J.2.10.2.1.5 J.2.10.2.1.4 J.2.10.2.1.24
10.		Authorization of payment via Government Purchase Card	G.4.8
11.		Alternate Billing Start Date	G.4.1.2
12.	SLA Management	TO-unique Key Performance Indicators (KPIs) and Service Level Agreements (SLAs) [Service Performance, Provisioning SLAs, Service Related Labor SLAs] including Provisioning Intervals for ICB Services; Rapid Provisioning Services, and Project Provisioning.	G.8.2.1, G.8.2.2.2, G.8.2.2.3
13.	SLA Management	SLA Management Deliverables: · Service Level Agreement Report (SLAR)	J.2.8.2 J.2.10.2.1.14
14.	Disputes	Dispute Deliverables · Dispute Report (DR)	J.2.6.2 J.2.10.2.1.10
15.	Direct Data Exchange	Additional Data Exchange Requirements specific to agency requirements	G.5.3.2.3

Appendix D Service Performance SLA References

D.1 Service-Specific SLA References

The KPIs defining each SLA are specified in EIS contract Section C in the subsection identified below for each service.

Service	Service ID	Section C Reference
Virtual Private Network Service	VPNS	C.2.1.1.4
Ethernet Transport Service	ETS	C.2.1.2.4
Optical Wavelength Service	OWS	C.2.1.3.4
Private Line Service	PLS	C.2.1.4.4
Synchronized Optical Network Service	SONETS	C.2.1.5.4
Dark Fiber Service	DFS	C.2.1.6.4
Internet Protocol Service	IPS	C.2.1.7.4
Internet Protocol Voice Service	IPVS	C.2.2.1.4
Circuit Switched Voice Service	CSVS	C.2.2.2.4
Toll Free Service	TFS	C.2.2.3.4
Circuit Switched Data Service	CSDS	C.2.2.4.4
Contact Center Service	CCS	C.2.3.1.7
Co-located Hosting Center Service	CHS	C.2.4.5.1
Infrastructure as a Service	IaaS	C.2.5.1.4
Platform as a Service	PaaS	C.2.5.2.4
Software as a Service	SaaS	C.2.5.3.4
Content Delivery Network Service	CDNS	C.2.5.4.4
Wireless Service	MWS	C.2.6.4.1
Commercial Mobile Satellite Service	CMSS	C.2.7.3
Commercial Fixed Satellite Service	CFSS	C.2.7.3
Managed Network Service	MNS	C.2.8.1.4
Web Conferencing Service	WCS	C.2.8.2.4
Unified Communications Service	UCS	C.2.8.3.4
Managed Trusted Internet Protocol Service – Trusted Internet Connection Portal	MTIPS-TIC	C.2.8.4.4
Managed Trusted Internet Protocol Service – Transport Collection and Distribution	MTIPS	C.2.8.4.4
Managed Security Service	MSS	C.2.8.5.4
Managed Mobility Service	MMS	C.2.8.6.4
Audio Conferencing Service	ACS	C.2.8.7.4
Video Teleconferencing Service	VTS	C.2.8.8.4
DHS Intrusion Prevention Security Service	DIPSS	C.2.8.9.4

D.2 Incident-Based Service SLA References

Service	Service ID	Section C Reference
Virtual Private Network Service	VPNS	C.2.1.1.4
Ethernet Transport Service	ETS	C.2.1.2.4
Optical Wavelength Service	OWS	C.2.1.3.4
Private Line Service	PLS	C.2.1.4.4
Synchronized Optical Network Service	SONETS	C.2.1.5.4
Dark Fiber Service	DFS	C.2.1.6.4
Internet Protocol Service	IPS	C.2.1.7.4
Internet Protocol Voice Service	IPVS	C.2.2.1.4
Circuit Switched Voice Service	CSVS	C.2.2.2.4
Toll Free Service	TFS	C.2.2.3.4
Circuit Switched Data Service	CSDS	C.2.2.4.4
Contact Center Service	CCS	C.2.3.1.7
Colocated Hosting Service	CHS	C.2.4.5.1
Infrastructure as a Service	IaaS	C.2.5.1.4
Platform as a Service	PaaS	C.2.5.2.4
Software as a Service	SaaS	C.2.5.3.4
Content Delivery Network Service	CDNS	C.2.5.4.4
Wireless Service	MWS	C.2.6.4.1
Managed Network Service	MNS	C.2.8.1.3
Web Conferencing Service	WCS	C.2.8.2.4
Unified Communications Service	UCS	C.2.8.3.4
Managed Trusted Internet Protocol Service – Transport Collection and Distribution	MTIPS	C.2.8.4.4
Managed Security Service	MSS	C.2.8.5.4
Audio Conferencing Service	ACS	C.2.8.7.4
Video Teleconferencing Service	VTS	C.2.8.8.4
DHS Intrusion Prevention Security Service	DIPSS	C.2.8.9.4

Appendix E Training

Agency personnel will receive training outlined in Section G.10 of the EIS contracts and reiterated below. For specific training that will be provided by your contractor, please refer to your contractor’s training guide.

The contractor will provide training described below at no additional cost to government customers, as part of the basic service. The contractor will train designated COs, authorized ordering officials, OCOs, and CORs to fully understand and use the contractor’s BSS, ensuring that each one becomes proficient in performing tasks that include, but are not limited to:

1. Use of the contractor’s BSS

2. Obtaining price quotes for services and features

3. Ordering services from the contractor via CLINs or ICBs

4. Placing order electronically to add, change, cancel, or disconnect services

5. Adding or changing the features, calling privileges, telephone number or other line attributes that can be changed via “soft” reconfigurations

6. Accepting or rejecting an order or part of an order

7. Reconciling billing

8. Initiating and tracking billing disputes

9. Initiating the inventory management process

10. Initiating and reconciling performance management (SLA) reports

11. Placing and tracking trouble reports for routine and emergency troubles

Appendix F Additional Resources

GSA provides EIS guides, handbooks and videos that address acquisition planning, ordering, transition, pricing, services and systems. All resources and information may not be currently available. To be notified as new resources become available, subscribe to http://www.gsa.gov/eis.

The Fair Opportunity and Ordering Guide (FOOG)

The FOOG provides detailed information on acquisition planning and decision/award functions and is available at http://www.gsa.gov/eistransition.

The Pricer Guide

The Pricer Guide explains the EIS pricing structure and price components of individual services. For additional detail please see http://www.gsa.gov/eis.

EIS Transition Website

GSA uses its public website as a centralized location for accessing transition information and tools. The transition website, http://www.gsa.gov/eistransition, is the home page for linking to these tools and requesting access to them as well as finding additional information and resources helpful to agencies and contractors involved in transition. The transition website shares transition status with all stakeholders. The information on the EIS transition website is specific to transition activities; updates on EIS and preliminary transition information is available on the EIS website at http://www.gsa.gov/eis.

Examples of information included on or linked to from the website are:

· Description of the TCC and services available

· Timeline and milestones

· Tips for preparing for transition

· Transition Inventory in E-MORRIS

· Training and video learning

· FAQs

· GSA contacts

· Hyperlinks to related web sites for Networx, WITS 3, GSA Regional local service contracts, EIS, TOPS, and E-MORRIS

· Guides, white papers and handbooks related to transition as well as the EIS contracts

· News articles and social media communications

EIS Transition Tools

The following guides, handbooks, and tools are available (as indicated) to assist agencies, contractors, and other stakeholders.

Transition Handbook (http://www.gsa.gov/eistransition)
TI Users’ Guide (http://www.gsa.gov/eistransition)
TI Quick Reference Guide (http://www.gsa.gov/eistransition)
Fair Opportunity and Ordering Guide (http://www.gsa.gov/eistransition)
EIS Management and Operations Handbook (http://www.gsa.gov/eis)
Solicitation and SOW Assistance Tool (SSAT) (http://www.gsa.gov/eis)
DPA Training (http://www.gsa.gov/eis)

Appendix G Use Cases

These use cases provide agencies with the steps to order, update, change/modify and accept services available under the EIS contracts.

Index of Use Cases

Use Case	Use Case Name	Use Case Description
G.1	New Service Install	Orders for new services that are not currently being provided by the contractor under EIS.
G.2	Move Order	Orders that require the removal of an existing service and/or SRE from one location and the re-installation of the identical service and/or SRE at another location. This will result in two line items on the SOCN (one to remove the service from the old location and one to add it to at the new location).
G.3	Change Order (Features)	Orders that require changes to the features of an existing service but do not require a change in the CLINs for the service. Note: Changes that require new CLINs are handled as a disconnect and a new install.
G.4	Change Order (Configuration)	Orders that require changes in the configuration of an existing service without adding or removing CLINs or features.
G.5	Update Customer Want Date (CWD)	Order updates that change the Customer Want Date (CWD) from that specified in the original order.
G.6	Disconnect Order	Disconnect orders are defined as orders that require the removal of services (CLINs) currently being provided. Contractors will accept disconnect orders at any time. Billing for the disconnected services stop on the completion date in the SOCN and within the provisioning intervals for disconnects as specified in Section G.8 Service Level Management. Equipment related to disconnect orders must be sanitized and removed within 45 days after the termination of services.
G.7	Cancel Order	Contractors will accept an order from an agency to cancel a pending order at any step of the order process prior to SOCN.
G.8	Update Service Location	Order updates that change the specified service delivery location from that specified in the original order but do not impact LEC provisioning.
G.9	Administrative	Administrative change orders are defined as orders that only require changes to administrative data associated with an existing service (CLIN) as described in Section G.3.3.2.2.4. Administrative changes provided by the government does not impact service delivery or pricing.
G.10	Auto Sold	CLINs that are bundled as part of another CLIN and automatically sold along with it.
G.11	Rapid Provisioning	Orders affecting services that are offered by the contractor under the rapid provisioning process, including: · Bandwidth-on-Demand · Cloud Services (See also H.12) · Any other services specifically identified as such by the contractor in its EIS contract

Service Order Data Elements

In accordance with EIS contracts Section J.2.10.2.1.15 Service Order, for all of the use cases in this Appendix and in all cases, the data set submitted by the government will contain sufficient information for the contractor to successfully complete the order and meet contract and TO requirements. The information that the contractor collects includes but is not limited to:

TO Number and TO Modification Number (if applicable)
Header Level Order Type
Customer Want Date and Early Installation Approval/Disapproval
Contact information for COR
Government project code (optional)
Line Item Details:

Line Item Level Order Type
If type is Administrative, See EIS contracts Section J.2.10.2.1.12 Administrative Change Order
AHC
ASRN(s)
CLIN
Quantity

Any comments from the government on handling the order
Any data elements necessary to successfully complete the order or required by the TO
If the header level order type is Supplement (see EIS contracts Section J.2.10.1.1.4.3), the government will include sufficient information to clearly communicate:

The order being updated (e.g. CSRN)
The line items being updated
Updates to be made

When submitted via the contractor’s web interface, the government will use the format required by that interface for this data set and will supply the data elements marked as required on that interface.

Note: The contractor is responsible for collecting all order information from the government necessary to complete all other deliverables. The contractor may, with OCO concurrence, further define how that data is provided - e.g. limiting the number of different AHCs or ASRNs that may be processed on a single order, requiring pre-registration of project codes, etc.

G.1 New Service Install

Section	Description
Use Case Name	New Service Install
Use Case Description	Orders for new services that are not currently being provided by the contractor under EIS.
Procedures	To place an order for new service installations, see the requirements listed above in Service Order Data Elements.
Roles and Responsibilities	· The OCO is the sole and exclusive government official with authority to take actions that may bind the government. · The OCO for each TO may designate COR(s) authorized to place and administer service orders within the bounds of the TO · Gather/define requirements · The COR prepares/submits the Ordering Form for the new service(s) to the contractor
Follow-on Steps	· The COR tests and accepts new services into operation
Links/References	· EIS RFP Section G.3 Ordering · EIS RFP Section J.2.4 Ordering

G.2 Move Order

Section	Description
Use Case Name	Move Order
Use Case Description	Orders that require the removal of an existing service and/or Service Related Equipment (SRE) from one location and the re-installation of the identical service and/or SRE at another location. This will result in two line items on the SOCN (one to remove the service from the old location and one to add it to at the new location).
Procedures	To place an order to move existing service(s) and/or SRE see the requirements listed above in Service Order Data Elements.
Roles and Responsibilities	· The OCO is the sole and exclusive government official with authority to take actions that may bind the government. · The OCO for each TO may designate COR(s) authorized to place and administer service orders within the bounds of the TO · Gather/define requirements · Prepare/submit the Ordering Form to move service(s) and equipment to another physical location to the contractor
Follow-on Steps	· Confirm the removal and re-installation of the identical service are complete
Links/References	· G.3.3.2.3.1 Move Orders · J.2.10.1.1.4.2.1 Move Orders

G.3 Change Order (Features)

Section	Description
Use Case Name	Feature Change
Use Case Description	Feature change orders are defined as orders that require changes to the features of an existing service. They fall into two categories: · Feature changes that require a change to the CLIN being billed · Feature changes that do not require a change to the CLIN being billed Note: Changes that require new CLINs are handled as a disconnect and a new install.
Procedures	To place an order to change features of an existing service, see the requirements listed above in Service Order Data Elements.
Roles and Responsibilities	· The OCO is the sole and exclusive government official with authority to take actions that may bind the government. · The OCO for each TO may designate COR(s) authorized to place and administer service orders within the bounds of the TO · Gather/define requirements · Prepare/submit the Ordering Form for the feature change to the contractor
Follow-on Steps	· Confirm that the feature change was completed
Links/References	· Section B of the EIS contracts · Section C.2 for service features · Section J.2.10.1.1.4.3.4 Update Specified Features · Section J.2.10.1.1.4.2.2 Change in Features

G.4 Change Order (Configuration)

Section	Description
Use Case Name	Configuration Change
Use Case Description	Orders that require changes in the configuration of an existing service without adding or removing CLINs or features.
Procedures	To place an order for changes in the configuration of an existing service, see the requirements listed above in Service Order Data Elements.
Roles and Responsibilities	· The OCO is the sole and exclusive government official with authority to take actions that may bind the government. · The OCO for each TO may designate COR(s) authorized to place and administer service orders within the bounds of the TO · Gather/define requirements · Prepare/submit the Ordering Form for the configuration change to the contractor
Follow-on Steps	· Confirm that the configuration change was completed
Links/References	· Section J.2.10.1.1.4.2.3

G.5 Update Customer Want Date

Section	Description
Use Case Name	Update Customer Want Date
Use Case Description	Customer Want Date (CWD) updates are defined as order updates that change the customer want date from that specified in the original order. If the agency delays the CWD prior to receiving the Firm Order Commitment Notice (FOCN), the contractor will not issue the SOCN and begin billing prior to the new CWD, unless the change requested is less than14 days before the CWD of the initial order.
Procedures	To place an order to change the CWD, see the requirements listed above in Service Order Data Elements.
Roles and Responsibilities	· The OCO is the sole and exclusive government official with authority to take actions that may bind the government. · The OCO for each TO may designate COR(s) authorized to place and administer service orders within the bounds of the TO · Gather/define requirements · Prepare/submit the Ordering Form for the updated CWD to the contractor
Follow-on Steps	· Test and accept new services into operation
Links/References	· EIS contracts Section G.3.3.2.3.4

G.6 Disconnect Order

Section	Description
Use Case Name	Disconnect Order
Use Case Description	Disconnect orders are defined as orders that require the removal of services (CLINs) currently being provided. Contractors will accept disconnect orders at any time. Billing for the disconnected services stop on the completion date in the SOCN and within the provisioning intervals for disconnects as specified in Section G.8 Service Level Management. The government will automatically stop payment on these orders based on the stated disconnect date. Equipment related to disconnect orders must be removed within 45 days after the termination of services. For equipment sanitization, see Section C.1.8.7.1.
Procedures	To place an order to disconnect existing service(s) or SRE, see the requirements listed above in Service Order Data Elements.
Roles and Responsibilities	· The OCO is the sole and exclusive government official with authority to take actions that may bind the government. · The OCO for each TO may designate COR(s) authorized to place and administer service orders within the bounds of the TO · Gather/define requirements · Prepare/submit the Ordering Form to disconnect service(s) to the contractor
Follow-on Steps	· Ensure the requested services, in whole or in part, were disconnected on the requested date · Ensure equipment related to disconnect orders is sanitized and removed within 45 days after the termination of services
Links/References	· Section G.3.3.2.2.3 Disconnect Orders · Section G.8 Service Level Management · Section C.1.8.7.1 Equipment Sanitization

G.7 Cancel Order

Section	Description
Use Case Name	Cancel Order
Use Case Description	Contractors will accept an order from an agency to cancel a pending order at any step of the order process prior to SOCN. Contractors will not charge the ordering agency for network access orders if the cancellation order was placed 30 or more days before the later of: 1. The CWD in the initial order, or 2. The firm order commitment date. If the government’s cancellation request does not meet the timeframe and requirements above, then the government will pay the non-recurring charge (NRC) for the associated access arrangements using the cancellation CLIN.
Procedures	To place an order to cancel a pending order, see the requirements listed above in Service Order Data Elements.
Roles and Responsibilities	· The OCO is the sole and exclusive government official with authority to take actions that may bind the government. · The OCO for each TO may designate COR(s) authorized to place and administer service orders within the bounds of the TO · Prepare/submit the Ordering Form to cancel service(s) to the contractor
Follow-on Steps	· Ensure the service(s) requested are cancelled
Links/References	· EIS contracts Section G.3.3.2.3.1 Cancel Orders

G.8 Update Service Location

Section	Description
Use Case Name	Update Service Location
Use Case Description	Location change updates are defined as order updates that change the service delivery location from that specified in the original order. They fall into two categories: · Changes in service delivery location that impact LEC provisioning · Changes in service delivery location that do not impact LEC provisioning
Procedures	To place an order for changes in the configuration of an existing service, see the requirements listed above in Service Order Data Elements.
Roles and Responsibilities	· The OCO is the sole and exclusive government official with authority to take actions that may bind the government. · The OCO for each TO may designate COR(s) authorized to place and administer service orders within the bounds of the TO · Gather/define requirements · Prepare/submit the Ordering Form for the location change update to the contractor
Follow-on Steps	· Confirm that the location change update was completed
Links/References	· Section G.3.3.2.3.2 Location Change Updates · Section J.2.10.1.1.4.3.3 Update Specified Location

G.9 Administrative Change Orders

Section	Description
Use Case Name	Administrative Changes
Use Case Description	Administrative change orders are defined as orders that only require changes to administrative data associated with an existing service (CLIN) as described in Section G.3.3.2.2.4. Administrative changes provided by the government does not impact service delivery or pricing. Changes to administrative data associated with existing services can only occur based on an administrative change order. Only the following fields fall into this category by default: · Agency Service Request Number 1 · Agency Service Request Number 2 · Agency Hierarchy Code · CLIN · Quantity Additional data elements can be subject to administrative change orders on a contract-wide or case-by-case basis with the mutual agreement of the contractor and the GSA CO.
Procedures	· The government will issue an Administrative Change Order specifying the inventory items to be changed and details of the change. · The contractor shall update its systems and submit a SOAC within seven (7) days of the Administrative Change Order.
Roles and Responsibilities	· The OCO is the sole and exclusive government official with authority to take actions that may bind the government. · The OCO for each TO may designate COR(s) authorized to place and administer service orders within the bounds of the TO · Gather/define requirements · Prepare/submit the Ordering Form for Administrative Change orders to the contractor
Follow-on Steps	· Test and accept new services into operation
Links/References	· EIS contracts Section G.3.3.2.2.4 · EIS contacts Section J.2.4.2.3

G.10 Auto-Sold

Section	Description
Use Case Name	Auto-Sold
Use Case Description	CLINs that are bundled as part of another CLIN and automatically sold along with it.
Procedures	To place an order for changes in the configuration of an existing service, see the requirements listed above in Service Order Data Elements.
Roles and Responsibilities	· The OCO is the sole and exclusive government official with authority to take actions that may bind the government. · The OCO for each TO may designate COR(s) authorized to place and administer service orders within the bounds of the TO · Gather/define requirements · Prepare/submit the Ordering Form for the location change update to the contractor
Follow-on Steps	· Confirm that the change was completed
Links/References	· Section J.2.4.1.7

G.11 Rapid Provisioning Process

Section	Description
Use Case Name	Rapid Provisioning Process
Use Case Description	Orders affecting services that are offered by the contractor under the rapid provisioning process, including: · Bandwidth-on-Demand · Cloud Services (See also H.12) · Any other services specifically identified as such by the contractor in its EIS contract
Procedures	To place an order under the rapid provisioning process, see the requirements listed above: · General order requirements in Section D.2, “Service Order Data Elements” · Requirements specific to order type in o Section D.3 New Service Install o Section D.6 Disconnect Order o Section D.8 Change Order (Features) o Section D.9 Change Order (Configuration) See also, restrictions in Section 4.5.5, “Rapid Provisioning”.
Roles and Responsibilities	· The OCO is the sole and exclusive government official with authority to take actions that may bind the government. · The OCO for each TO may designate COR(s) authorized to place and administer service orders within the bounds of the TO · Gather/define requirements · Prepare/submit the Ordering Form for new, disconnect, move or change services to the contractor
Follow-on Steps	· Confirm the requested action was completed including testing and acceptance as appropriate.
Links/References	· EIS contracts Section G.3.3.3.2, “Rapid Provisioning Orders” · EIS contracts Section G.8.2.2.4, “Rapidly Provisioned Services” · EIS contracts Section J.2.4.2.4, “Rapid Provisioning”