Q&A #8
RFP #R582581
Question:
If service is terminated into an AREON Hut, are there any additional fees for rack space, power, fiber entrance facilities?
Answer:
If a service provider desires to co-locate in an ARE-ON hut, they will have to pay ARE-ON standard charges. However, if a provider is already co-located in an ARE-ON hut, there would not be any additional fees for establishing the peering arrangement.
Question:
Is the AREON network capable of the CoS required for VoIP once service is terminated into the AREON facility?
Answer:
Yes.
Question:
The RFP mentioned just one AREON Hut; are multiple locations required for additional growth?
Answer:
Significant growth is not expected at the University of Arkansas System Office.
Question:
Is the number of seats for the phone system the same as the number of seats for the call center?
Answer:
No, there are only expected to be three seats for the call center.
Question:
How many agents? How many supervisors?
Answer:
Our initial implementation would include 3 agents and 1 supervisor.
Question:
Do the agents share roles or do they have different roles?
Answer:
At the time, all agents have similar roles.
Question:
Will agents need web-chat, email access, and voice access?
Answer:
Yes.
Question:
Will all agents need call recording, quality monitoring, scoring, feedback, scheduling and forecasting?
Answer:
Yes.
Question:
How many surveys do they want to send out each month and will it be a single survey or multiple types of surveys?
Answer:
Our specific requirements have not been finalized. You can assume minimal usage initially.
Question:
Do they have IVR’s today? Can they provide call flows and scripts on what they have or what they want?
Answer:
We do not currently have this functionality. We currently have a small team of academic advisors who will be receiving questions from students. This could grow to include a larger team stepping students through the application, enrollment, and financial aid processes. IVR functionality at this time would mostly consist of answers to a few "frequently asked questions" that can be answered after-hours or when no representatives are available. We are also likely to use IVR to automate "receptionist" functionality on several main contact numbers.
Question:
What database do they need to dip? Does it support web-services or open API’s?
Answer:
Our student records system is Ellucian Banner, running on an Oracle database. A future application version should support web-services, but the current version would require SQL integration.
Question:
Do they want a screen-pop to the agent desktop? What criteria will they use to identify the caller?
Answer:
Screen-pop functionality is not critical. Callers will be identified by either a unique student identifier (ID number, username, or email address) or a combination of personal information (name, birthdate, etc.).
Question:
How many numbers are pointed to the contact-center? Are they local or toll-free? How many of each? Who is the current telecom provider?
Answer:
We are not currently using any ACD functionality. Our initial deployment would be single local number. Our current telecom vendor is the Arkansas State Department of Information Systems.
Question:
How many departments are there with call centers and how many agents/supervisors per department?
Answer:
Currently one department comprising the 3 agents and 1 supervisor previously mentioned.
Question:
Does your contact center experience seasonal call spikes? (Fall enrollment, etc.)
Answer:
We expect to see moderate spikes as a result of advertising campaigns, but our academic calendar has seven six-week terms spread across the entire year so we should not see the traditional fall/spring/summer peaks.
Question:
Are there any outbound calling requirements? Preview dialing? Predictive Dialing?
Answer:
No requirements identified at this time.
Question:
Are there any self-service applications for the IVR system that could help offload some of the call volume? i.e. check a balance, has a check been deposited, is tuition paid?
Answer:
We have not identified any self-service applications that would require dynamic responses.