The system’s single entry point allows access to all of Sercom’s operation and management applications, offering both simplicity and security. Access to the different applications depends on the user’s profile and domain. This single entry point consists on Sercom’s authentication web application, requiring only an Internet browser to be installed on the user’s computer.

The Agent Desktop Tool is a .NET technology desktop application that remotely communicates with SERCOM. It offers the user all the necessary elements to keep control over the ongoing calls and to access all the information associated with these calls.

The Agent Desktop Tool’s installation is carried out through the system’s single entry point. Updates are performed automatically, if necessary, every time the application is run.

The Agent Desktop Tool is divided in three functional areas, clearly showing the actions that can be carried in each one of them.

1. Telephony Control Bar
2. Business Application Area
3. Tools Area.

TCB Telephony Control Bar

The Telephony Control Bar, located on the upper part of the screen, you can find the controls for typical CTI functions such as log into a session, set the agent’s state or control ongoing calls.

Specifically, the Telephony Control Bar allows:

1. Open or close a work session on any operator seat.
2. Login or logout from the ACD-groups pre-assigned by the administrators for each agent.
3. Change the agent’s state to READY, NOTREADY or WORKNOTREADY. The agent can qualify the state change by choosing one among the qualifiers previously defined by the administrators.
4. Call handling by means of specific controls: Dial, Hang-up, Hold, Retrieve, Transfer, Conference and Deflect.
5. The agent can set the termination cause for the call by choosing one among the different sets of causes defined by the administrators.
6. Launch different operations upon the call, such as recording it, as long as the configuration allows it.

BAA Bussiness Application Area

The Business Application Area is located in the center of the screen. It’s an embedded browser on which the agent’s application is launched. This application is the one needed by the agent to handle the business process associated with each call, such as CRM. This application handles information very specific to the caller and therefore is implemented outside of Sercom’s realm.

To integrate Sercom and the client application, the embedded web browser invokes an URL, for each call, with parameters such as CAMPAIGN, ANI or DNIS. These parameters are used by the web application to retrieve the relevant data from a database.

The URL that is established at each time is established by system administrators at system configuration.

The Business Application Area has the capability of keeping simultaneously opened several web pages arranged in tabs. This is especially useful when the agent has several calls.

TA Tool Area

On the right part you can find the Tools Area where a set of different useful tools are arranged in tabs:

1. Personal Monitor, it shows information related to the total time the agent has been in conversation, the idle time, the time at each logical state, and the number of answered calls.
2. Queue Monitor, it shows information related to the ACD-Groups queues in which the agent is logged in, as number of queued calls and the time queue waiting time.
3. VideoIP Softphone, complete video IP phone software SIP and H.323 technology to be used just in case there is no physical IP phone available.
4. Telephony Keypad it allows to handle the Video IP phone avoiding the use of the Telephony Control Bar, an element outside of SERCOM.
5. IM Chat Client a client for communications established by means of this kind of Media.
6. Video & Audio Settings it adjusts several parameters that in some cases may be needed to change during a call.

The layout and size of all this parts of the Agent Desktop Tool can be customized by the user allowing a comfortable and useful work environment that eases his daily work.

Administration tool is the application that registers in SERCOM all the different functional items that define the system operative. Due to the fact that it is a WEB application is not necessary for the user to install any other additional software. Just an internet browser with the Macromedia Flash plug-in make the things work.
The list of administrative tasks that can be performed with this administration application are:

1. Resources repository management, that is: campaigns, calendars, FLEXRouting vectors definition, queue sizing, announcements arrange
2. Agent list and its associations to ACD-groups can be done just by Drag&Drop
3. Dialling plan management and dialling rules setting for least cost routing.
4. Domains and Subdomains management, FLEXRouting prompting and decision devices, ACD and Hunt-Groups.
5. Adding and deleting Trunks, Stations and the inclusion of needed technologies depending on the installed hardware.

An example of this application’s menu can be seen in the following screenshot: Depending on his role, the user will manage more or less system elements. Roles are:

1. Supervisor
2. Domain Administrator
3. System Administrator

El Supervisor

The Supervisor role can change the configuration of the announcements, queues, campaigns and users, but can’t add new numerations, although it is possible for him to change the allocation of the agents to the existing ACD-Groups.

The Domain Administrator

The Domain Administrator role can add and delete agents, add new numerations, and even creating ACD-Groups and subdomains. Obviously he can perform all the tasks that are available for the Supervisor role.

The System Administrator

The system administrator role can add the hardware elements relative to the system, such as, stations and trunks. He also can insert new Technologies and add or delete domains.
In the following table you can see the different operations allowed depending on the role:



All the changes done in the system configuration are available without any system restarting.

The Reporting web application offers a set of reports that cover the main necessities of any Contact Center. The gathering of the information for these reports is utterly separated by each domain. It is also possible to separate them by subdomain where available

The gathering of the information for these reports is utterly separated by each domain. It is also possible to separate them by subdomain where available

1. From Date/ Time
2. Until Date/ Time
3. Subdomain
4. Campaign

The reports can be shown on the screen in the following formats:

1. HTML Web Page
2. PDF Adobe Portable Document Format
3. RTF Microsoft Word Native Format

There’s also an export option that gets the reports as:

1. PDF Adobe Portable Document Format
2. XLS Excel SpreadSheet
3. XML Extensible Markup Language
4. CSV Comma Separated Values
5. RTF Microsoft Word Native Format

The reports that can be obtained are the following:

1. Contact times: Report that details the different inverted times summarized by the cause of the contacts.
2. Answered time in detail: Report that details in time slots of 15,30,45 or 60 minutes, the number of answered contacts, the time speaking, queue time and the average time by operation.
3. Contact status: Report that details the summary of the state of the contacts.
4. Contact status cause: Report that details the cause of contact’s state grouped by the cause.
5. Inbound service level. Variant 1: Report that details answered and abandoned contacts, its percentage and the waiting times, in addition calculates the service level (Variant 1 according to ECTF R.100)
6. Inbound service level. Variant 2: Report that details answered and abandoned contacts, its percentage and the waiting times, in addition calculates the service level (Variant 2 according to ECTF R.100)
7. Inbound service level. Variant 3: Report that details answered and abandoned contacts, its percentage and the times waiting, in addition calculates the service level (Variant 3 according to ECTF R.100)
8. Inbound service level. Variant 4: Report that details answered and abandoned contacts, its percentage and the waiting times, in addition calculates the service level (Variant 4 according to ECTF R.100)
9. Queue summary: Report that details the summary of the queue, where the totals of calls, the times of delay and the level of tolerance are specified.
10. Abandoned inbound contacts grouped by waiting time: Report that shows the summary of abandoned contacts specifying the seconds that the contacts waited before abandon.
11. Inbound answered contacts grouped by speaking time: Report that shows the summary of answered contacts / answered specifying the seconds of conversation of the answered contacts.
12. Rejected inbound contacts grouped by waiting time: Report that shows the summary of rejected contact specifying the seconds that contacts waited before being abandoned.
13. Inbound answered contacts grouped by waiting time: Report that shows the summary of answered contacts specifying the seconds waiting of the answered contact.
14. Inbound service summary: Report that shows the summary of the number of incoming contacts in the different states specifying average times and maximum times waiting, times of conversation and time of contacts answered without wait.
15. Outbound domain service summary: Report that shows the summary of the number of outgoing calls in the different states specifying the average and maximum times from progress, times of conversation.
16. Failed outbound contacts grouped by progressing time: Report that shows the summary of failed contacts specifying the seconds that were progressing the calls before being failed.
17. Chart of total number of inbound contacts: Report that shows the chart with the number of contacts, showing the information in time slots of one hour.
18. Chart of speaking time in inbound contacts: Report that shows the chart with the conversation time, showing the information in time slots of one hour.
19. Chart of average operating time in inbound contacts: Report that shows the chart of the average time of operation (ATO), showing the information in time slots of one hour.
20. Catalogued contacts, summary: Report that shows the summary of the catalogued contacts.
21. Contact Detail: Report that shows the detail of the contacts depending on the applied filter.

Using a web browser (which, only needs the Java plug-in installed), by means of this WEB tool it is possible to monitorize several system element. The monitoring is performed in real time and its main goal is to show a system screenshot. It doesn’t replace the reporting application but complements it.

Each element suitable to be monitorized has a number of properties that can be shown or not, depending on how them have been configured in the monitoring application. There are several visualization modes for each element:

1. Items List View
2. Grid View
3. Graphic View

The Item List mode consists on showing the monitorized elements by means of icons representing them. Next to each icon the view shows all their properties and their real values.

In the Grid View, the columns represent each of the available properties in the monitorization and the rows the object (the element) that is going to be monitorized, one per row.

Finally with the graphical mode it is possible to represent the main property of each element in bars or pie charts.

The monitoring application has also a part where certain alarms thrown by the system are shown. Among this alarms are:

1. Call Queued lost
2. Call queued excessive time waiting

The following elements and entities are suitable to be monitorized:

ACD

Entity that represents contacts delivering groups for the agents that are under a same skill or ability to deal with the contacts.

In this case it shows the number of agents associated to the ACD in the following states:

1. Ready. (Ready for accepting a contact)
2. NotReady (not ready for accepting a contact).
3. AdminWork. Not ready because doing administrative tasks: backoffice ...
4. Busy. Not ready for accepting a contact, for being working with another contact.

SUBDOMAIN

Entity that groups a set of campaigns, acds and agents (users). This union usually correspond to a set of related services that typically are under a Supervisor or Coordinator responsibility.

The following info is shown:

1. AgentCount. Number of configurated agents.
2. QueueCount. Number of configurated queues.

CAMPAING

Entity that represents a set of features of a campaign such as: kind of campaign, Scope, supported Media… that allows it to receive certain contacts.

It shows the following info:

1. ContactRate. Number of attended contacts per minute.
2. InboundCnt. Number of received contacts.
3. OutBoundCnt. Number of diales contacts.

QUEUES

Entity that represents the container the ACD needs to temporally keep the contacts while they’re waiting for being attended by an agent.

It shows the following info:

1. LongestWaitingTime (LWT). Time of the contact that has been busy the longest time in the same position in a waiting queue.
2. AverageSpeedToAnswer (ASA). Average waiting time of the contacts that were in a waiting queue.
3. ServiceLevel (SL). Statistical Ratio that represents the % of attention for a contact in seconds since it was accepted in the ContactCenter. i.e. 80/20 attention of 80% of the calls before 20 seconds after the contact accepts the call.
4. Queue Ocupation. Number of contacts that are in a waiting queue.

USER

Entity that represents the users working on the system.

It shows the following info:

1. State of an agent. It can be: Ready, NotReady, AdminWork, Busy, Logged, LoggedOff. 
2. Valid Contacts. Number of answered contacts.

They model a communication or session between users of the system.

They have a unique identifier and carry all the information needed to describe how this communications has to be treated.

Calls are the only elements that are not preconfigured in the system. They are created and destroyed dynamically, lasting only as long as the communication they represent.

Endpoints correspond to physical or logical elements whose purpose is to interact among them, to establish a data stream or some sort of communication between them. Usually, this interaction results in an audio or video stream that communicates both endpoints. This communication is represented, as previously mentioned, by a Call.

Physical endpoints correspond to analog phones, IP phones, softphones, IP gateways and any other device capable of transporting the contents of a communication to a person.

Logical endpoints don’t have a corresponding physical device but participate in the call either by altering the communication or the logical properties of the Call element that represents it.

Every endpoint is previously configured in the system. It has a unique identifier as well as a reference to the external system it represents, such as a phone number, a SIP URI, etc.

Stations are endpoints representing Terminal equipment used by the system’s users to obtain a communication.

There has to be an endpoint for every softphone, IP phone or analog phone that is or could be connected to SERCOM. They are all considered as internal elements of the system.

Stations have properties to be configured by System Administrator only from Configuration Application. These properties are technology dependent.

Trunks are used to communicate with other systems, external to the SERCOM system itself. These communications are carried over these endpoints whose purpose is to act as a proxy of the external system.

Trunks have properties to be configured by System Administrator only from Configuration Application. These properties are technology dependent.

Every element configured in SERCOM is defined within a Domain. The system does not allow visibility between domains.

Therefore, it is possible to define EndPoints, Campaigns or whichever other element is needed with the same names as long as they reside in different domains.

They can coexist in the system, allowing the configuration of virtual platforms completely independent among them but sharing the same physical infrastructure.

SubDomains represent the same concept as the Domain, but with weaker isolation. It is designed to allow the creation of independent workgroups within the same Domain but with a reduced visibility between them.

The following table shows the SudDomain and Domain relation:

Directory Numbers (DN for short) are labels that make up the dial plan of the system. These labels are the strings that have to be dialled in order to reach any endpoint in the system. Therefore these are the only references the users need to know.

Endpoints can only be reached by the users by means of these DNs. Any endpoint will be reached from another endpoint simply by dialling its DN.

There can be several DNs associated to a single endpoint, allowing it to be reached by dialling any of these DNs

A DN has the following properties to be configured by Domain Administrator:

• Identifier
• Associated Device
• DN Type

The associated Device must be up defined in the system in order to associate this DN to it.

Provided that the DNType is LOCAL, the Identifier must be unique within the Domain, whereas when the DNType is SERVICE it must be unique within the system.

The DNType will be LOCAL if it corresponds to an internal number, and it will be SERVICE if it corresponds to an external number or system's DNIS.

SERCOM keeps a calendar repository. For each calendar, two kinds of intervals can be defined:

• Yearly Intervals, which are defined for every day in the year.
• Weekly Intervals, which are defined for each of the seven days in the week.

Each interval has the following features:

• Day of the year (just yearly intervals)
• Day of the year (just weekly intervals)
• Starting hour (10 minutes graining)
• Ending hour (10 minutes graining)
• Identifying Name

There's no upper or lower limit to the number of intervals that can be set for each calendar. Inside the same calendar, time overlapping of intervals of the same kind is not allowed, prevailing yearly intervals over weekly ones in case intervals of different types overlap.

Each calendar has an identifying name to which the rest of SERCOM's elements refer.

The main uses of calendars are:

• Campaign selection
• Decision element in FLEXRouting
• Agent's schedules' validation

During the process of assignment of a Campaign to a Call, among other choice criteria, the calendar associated to this Campaign is checked. Thanks to this feature, it is possible to share one same DNIS among several Campaigns, taking into account day and hour.

In the FLEXRouting decision nodes, it is possible to request as much calendars as needed in order to the internal call's target to be turn over.

The schedule within which an agent is allowed to open a working session can be set by a calendar. It is not allowed to force a session to be opened or closed automatically.

All the announcements to be used in the system, either messages for waiting queued calls or any other uses, must be contained in the announcements repository. There’s no limit in the number of announcements that can be saved.

The main features that define every announcement are as follows:

• Name or Identifier
• Kina of Media of the announcement
• URL for the file that contains the announcement Media
• Codec
• Bitrate
• Timeout

All the SERCOM’s elements that need the broadcasting o fan announcement refer to it by means of its name or identifier.

The Media can be:

• Voice
• Video
• Chat

It is used to check the suitability of the announcement for each type of call.

The URL informs where can be found the physical media with the announcement itself. SERCOM must have access granted to that address when needed.

The Codec describes the message format when it’s impossible to figure out from the message itself. In that case it is described as the payloads of the SDP protocol SDP in the RFC2327

The Bitrate indicates sampling frequency of the message when it is impossible to figure out from the message itself.

The Timeout is the maximum number of seconds for the announcement to last. Due to the fact that by means of the URL it is possible to refer dynamic contain generators, sometimes it’s not possible to foreknow the duration. In this way we set a maximum duration. A 0 value overrides the Timeout.

SERCOM keeps a repository with all the campaigns created by the administrators, there’s no limit for the number of campaigns. Each campaign is a set of common properties for the calls.

With any new call SERCOM follows two essential steps as far as the campaign is concerned:

• Selection of the most suitable campaign for the call according to the call itself.
• Association of the call to the selected campaign to apply the defined treatment in the campaign.

Following the two steps described before we get two main goals:

• To define the treatment applicable to the call and who’s going to attend it.
• It allows grouping calls by campaign in the reporting system.

Each campaign has two sets of properties:

• Selection Properties, their goal is to determine which the most suitable campaign for a certain call is.
• Treatment Properties, they indicate which are the actions to apply to all the calls associated to the campaign.

The data that SERCOM uses to select the most suitable campaign for each call are the following:

• Enabled Flag
• Scope
• Calendar
• Interval Name
• DNIS
• ANI

The Enabled Flag indicates if the campaign must be taken into account in the selection process. It allows the temporal deactivation of the campaign.

The Scope indicates the type of calls for which the campaign is suitable:

• Inbound
• Outbund
• Blended

The Calendar indicates against which interval the system must check the interval of the call, that is, the Interval Name. If no calendar is set, the system doesn’t perform any checking.

The interval Name must match to the Calendar at the time in which the call is being made. If it doesn’t match, the campaign is discarded.

The DNIS or at least a part of it must match with the one that has the call. If not, the campaign is discarded. If no DNIS is set, the comparison is not done.

The ANI or at least a part of it must agree with the one that has the call. If not, the campaign is discarded. If no ANI is set, the comparison is not done.

In the case that at the end of the selection process there were still several campaign that match with all the requisites, the first one will be selected.

Once the campaign is selected and a call is associated to it, the following campaign’s features are used to define the treatment to apply to the call:

• Priority
• Vector
• Finalize Causes
• Wrap-up Time
• Hold Announcement
• Recording Flag

The Priority gives a value to the call according to the rest of the calls of other campaigns just in case the call must stay in a waiting queue, allowing in this way set a priority to attend certain campaigns instead of another’s. Its default value is 0. It can also have positives or negatives values.

The Vector is the sequence of operations and checkings that a call does until it reaches its destiny inside the system. Each campaign reffers to a Vector. It’s compulsory to indicate a vector for the call. On the contrary the call won’t have any destiny in the System.

The Finalize Causes are a set of causes available for the agent that attends the call. The agent must choice one. There’s no limit in the number of causes to establish. This is very useful because it is possible to get reports grouped by causes in the Reporting application.

Wrap-up Time is the time that the agent has to indicate a Finalize Cause once the cal is finished.

Hold Announcement is the announcement to broadcast when the agent put the call on Hold mode. It allows broadcasting personalized messages for each campaign. It is completely different from the messages of the waiting queue.

Once the RecordingFlag is activated it also actives the recording of the calls of the campaign.

The campaigns are monitorized by means of the monitoring application. The following information is available:

• Number of ingoing calls since the beginning of the session.
• Number of outgoing calls since the beginning of the session.
• Number of total calls in the last 60 minutes

When a call can not be answered it should be queued in a Waiting. This is accomplished transferring the call to an ACD-Group that stamps on it an ID ticket containing the call identifier in the associated queue. In the meantime the ACD-Group gives a prerecorded prompt to the caller and monitors the queue’s associated agents group offers waiting any of them to be free.

By means of the appropriate configuration each ACD-Group handles is own queue, or different ACD-Groups can handle a common one, hence allowing different scenarios. There is no limit in the number of queues that can be configured.

With this operational differentiation the ACD-Groups take care of his agents handling and don’t bother about the queue management or call priority processing. The waiting queues are FIFO.

In SERCOM Queues, two concepts come together:

• Universal Queue: SERCOM allows handling in the same waiting queue, voice, video and chat.
• Prioritized Queue: Each queue maintains its own priority scheme that can alter the natural FIFO queuing. The call priority can be changed on the fly while being the call in the queue.

According to the number of items, any queue can have any of the following status:

• Empty
• Free
• Saturated
• Blocked

Queue status can be queried by vectors during the FLEXRouting to anticipate the known situation to give the caller (or the system) the more efficient alternative.

The Empty status corresponds to a queue with no call on it.

The Free status is when the queue has a number of calls lower than the configured threshold.

The Saturated status indicates that this threshold has been overridden, even if more calls continue to queue.

The Blocked status avoids any other new call to be queued, after reaching the maximum size configured.

Each Queue has his own properties that have to be established by means of the configuration application:

• Identifier name
• SLA
• Saturation threshold
• Blocking threshold
• Max size queue for SLA

Queues can be monitored in real time by the monitoring application giving the following information:

• Queue status.
• Blocking threshold, equivalent to the queue size.
• Saturation threshold.
• Number of calls in queue.
• Waiting time of the oldest call that upon the chosen priority scheme doesn’t have to be the next one to leave the queue.
• Waiting time of the next call to leave the queue that upon the chosen priority scheme doesn’t have to be the oldest one.
• Mean time in queue of waiting calls.
• Queue’ SLA, corresponding to the % of calls that have been waiting less than N seconds.

Agents are grouped around ACD-Groups to participate in the call distribution. There is no limit in the number of ACD-Groups that can by set up in the system, and each agent can belong to one or more ACD-Groups simultaneously. Their setup is available in the configuration tool’s menu “Distribution”.

Each ACD-Group has a LOCAL type DN assigned within the numbering plan, so any call can be transferred to an ACD-Group by simply invoking his number ID.

Together with ACD-Groups the administrator can establish different types of Agent’s groups according to their skills and type of service they can provide.

His definition allows the administrator to define first and second level seats, language skills, areas of knowledge, seniority/expertise, and define jumps of the incoming call between them. Some Agents might fulfill more than one profile; hence they can belong to more than one group of skills.

ACD-Group is the entity that permanently monitors its Agents activity, if they are or not busy, and decide the next one to take the call, respecting the queue FIFO.

As far as one Agent can belong to more than one ACD-Group simultaneously, in case of been available, a priority system between each ACD-Group, defines the next call to be deserved to this free Agent at a time.

The priorities that can be configured for each ACD-Group are as follows:

• Announcement
• Queue
• Timeout
• Distribution Type
• Queue Closed

Announcement is the one to be given to the caller while waiting in the queue.

Queue ID used by the ACD-Group to queue the call while waiting free Agents availability.

Timeout giving the allowed maximum time in queue for this ACD-Group. Once this time expires the ACD-Group invokes the FLEXRouting process with the TIMEOUT argument so that specific treatment can by applied to this call.

Distribution Type, as far as ACD-Group have different modes to select the Agent:

• None
• Round Robin
• The most idle
• Optimal Skill

Queue Closed, avoids adding new calls to the queue, so in case of non available Agents, the FLEXRouting process is invoked with the CLOSED argument to force an alternative treatment to this call. The outstanding calls in the queue will not be affected and will be served to the logged Agents as they get ready to take calls.

Once a campaign is defined in SERCOM and a new call enters, a process is awaked to find the most appropriate destination for it, taking in account different decision criteria.

This process is what we call FLEXRouting and in this process can be involved several elements as calendars, queues, prompting devices that make questions to the caller, or even logical devices that gather the needed information from external sources. These external sources can be DD.BB or any entity closer to the business or inner operation itself that to SERCOM.

The main element of this process is the Vector which is a call flow descriptor that follows very simple rules that invoke, fork and wait for response from other elements.

SERCOM maintains a Vector repository to be used from campaigns or from other vectors, allowing to buildup whole libraries with much or lesser complexity.

Each vector has a single entry point. Starting this entry point any number of branches could be added. The tree-like structure is not limited in depth.

Each entry has an ID and one associated command. The command execution can give as result the identifier of a next entry point to fork to at a deeper level of the tree and to continue the FLEXRouting processing the next command.

Each Vector entry point is depicted as a line that contains the following elements:

• Identifier
• Command
• Destination
• Parameters
• Label

Identifier is the element that identifies each entry point between others at the same fork level. It’s mandatory as it’s used in the command response to decide the new entry point to be executed. It must be unique between same bifurcation level’s entry points. If SERCOM does not find matching entries, the call will stay without destination.

Command is the action to be executed at each entry point. The returned value can be a text string to be interpreted as the next identifier on a lower level. Example of commands is: Deliver, Time Check, Call Vector, go to, queue check.

Destination is not mandatory and changes upon the type of command used. Type of available destinations is:

• Device
• Calendar
• Queue
• Vector
• Label
• Campaign

Parameters allow sending additional information as arguments to the Command’s destinations. They can be both plain text and variable names that SERCOM will recognize and update with current values:

• %DNIS%
• %ANI%
• %CAMPAIGN%
• %CONTACTID%
• %RESULT%

Label is an optional element, but if specified it must be unique amongst all other vector’s entry points as it’s used to make unconditional jumps between them.

Commands to be used are:

• Deliver
• TimeCheck
• QueueCheck
• Goto
• CallVector
• Return
• SetCampaign

Deliver command as always a SERCOM Device as argument. These devices can be ACD-Groups or Stations, where de call is delivered. However, as we’ll see later it’s possible to deliver to Prompting Devices that interact with the caller and return values as the next Vector identifier or even system Devices that can access external WebServices returning other values.

TimeCheck query calendars when invoked. The returned interval is then used to get the next entry point. Interval names are freely definable by the user administrator when configuring calendars.

QueueCheck returns the queue status when invoked. Valid values are:

• EMPTY
• FREE
• SATURATED
• BLOCKED

Response will be used to get the identifier of the next entry point to go to.

Goto allows unconditional jump within the current vector.

CallVector launches the execution of another vector stored in the corresponding repository. The execution of this final vector will return a response, again used to search for the next entry point. In that way it’s easy to build Vector libraries that hide complex or iterative tasks.

Any Vector called from another vector can resume the result of its execution with the Return command.

SetCampaign allow assigning again the call a Campaign. Even if the Campaign was already set, the FLEXRouting process can change it, either by customer wish or any other reason. Once the call assigned to a new Campaign, his associated Vector will be executed.

Follows a brief example of a Vector with comments:

The first step is to check in CALENDAR1 if the incoming call is while been on a WORKABLE or Holiday’s interval.

In case of being a WORKABLE interval the QUEUE1 status is checked.

1. If QUEUE1 is blocked, an external query to a Webservice is done giving the %DNIS% as argument, to get preferred destination.
2. Next the call is transferred to the returned value in the previous query. This number can be external to SERCOM.
3. If QUEUE1 is free the call will be delivered to the working ACD-Group ACDGRP1.
4. If QUEUE1 is saturated the call will be delivered to the reserve ACD-Group ACDGRP2 not to block QUEUE1
5. If CALENDAR1 says it’s HOLIDAY the call is transferred to a Prompting Device that will carry out the caller identification based on his ANI through an internal DD.BB query and by asking him to press “1” for automatic service or “2” to be answered by the reserve team on ACDGRP2.
6. If “1” is pressed, Vector IVR1 from vectors repository is invoked (automatic response system), and if “2” is the user’s choice there is jump to label TEAM2 of the vector that will deliver the call to ACD-Group ACDGRP2

The above example shows the power of FLEXRouting in a very basic way. Other cases cover different scenarios that fulfill all the needs of a Contact Center.

They play the role of specific FLEXRouting participants. They are Devices that have the ability to interact with a caller giving notice by means of pre recorded prompts and asking for DTMF entries. The caller DTMF answers will be used to determine the next entry point in the current vector. Like ACD-Groups they have a LOCAL type DN associated with the numbering plan, so any call can be diverted to them. So they act as IVR subsets to gather information for optimizing the call routing.

Prompting devices are to be configured in the Routing (IN) menu on the administration application.

The main features of these elements are:

• Announcement
• Digits
• Timeout
• Silence
• Cancel
• Buffer Clear

Announcement is the prompt file to be listened by the caller. They have to be activated in the SERCOM’s announcements repository. Announcements are multichannel so the caller might receive a video announcement.

Digits are the number of DTMF digits the system waits for. Default is #1.

Silence is the number of seconds after a DTMF is issued to consider the digits number capture closed.

Timeout is the total number of seconds allowed for the digit caption sequence before it finishes.

The Cancel parameter causes announcements to be disabled as soon as any DTMF is issued by the caller.

Buffer Clear allows ignoring any DTMF caption previously stored in the capture buffer.

Once the DTMF caption is finished, the call is back on the FLEXRouting process and the input received from user will indicate the next action or fork to take.

These Devices are similar to Prompting’s ones, as far as they are also classified in the Routing(IN) group, but in this case they do not make any interaction with the caller and only query a WebService.

In this way, business applications external to SERCOM can also contribute to the routing process to select the most efficient destination for a call.

For example on a call blending group of seats, any incoming call back from a previously contacted customer could be answered by the same seat that issued the first call to him. And this as soon as a Query Device invokes an external WebService linked with the existing auto dialer/CRM application

Properties available to use these Devices are:

• WebService’s URL
• Method

The needed URL to access the WebService should be accessible to SERCOM in the right moment.

The demanded WebService method parameter is mandatory and should accept a text string as argument. The result will be another text string that will be processed by the FLEXRouting.

Outbound dialing can be customized using routing rules to choose between different outgoing trunks, carriers or networks. These rules can also "transform" dialed strings, adding the ability to switch providers when a Call is just leaving the Contact Center. This is usually known as least cost routing, because the CC Admin can select the best provider for each type of Call.

This DialOut Rules enable the system to automatically select the Campaign for a Call, based on some dialed string pattern. This can help to complete accounting of all CC calls, even those that are manually dialed by Agents.

SERCOM stores all DialOut Rules in a common repository, with no limit on their count or their usage. For each outbound call SERCOM searches this repository, if it finds pattern matching with a Rule, the rule is then applied for that call.

The following properties are defined for each DialOut Rule:

• Calendar
• Interval
• Access Prefix
• Access Sufix
• Keeps Prefix
• Keep Sufix
• Extra Prefix
• Extra Sufix
• Associated Campaign
• Destinity DN
• Destinity Vector
• Enabled

Calendar: this enables that certain Rules are only "active" in specific timeframes.

Interval: this is the Calendar's Tag which will consider the Rule as "active". If the Calendar returns any other tag (other timeframes) the Rule will be ignored.

Access Prefix: This is the pattern to be searched at the beginning of all outbound call's destination string. Any call that matches this Rule's property, will be applied that rule. If there are simultaneous matching on many Rules, the most restrictive one will be applied, i.e. the Rule with the longest AccessPrefix.

Access Suffix: This is the pattern to be searched at the end of all outbound call's destination string. Any call that matches this Rule's property, will be applied that rule. If there are simultaneous matching on many Rules, the most restrictive one will be applied, i.e. the Rule with the longest AccessSuffix. Access Suffixes are searched after Access Prefixes matching is not found, so the prefix has "precedence" on the suffix for DialOut Rules matching.

Keeps Prefix: This property indicates if the matched Access Prefix needs to be kept or removed from the outbound call's destination string (address or number).

Keeps Suffix: This property indicates if the matched Access Suffix needs to be kept or removed from the outbound contact's destination string (address or number).

Extra Prefix: Additional prefix to be automatically appended at the beginning of the outbound call's destination string (address or number).

Extra Suffix: Additional suffix to be automatically appended at the end of the outbound call's destination string (address or number)

Associated Campaign: This is an optional parameter, which allows assigning a specific Campaign to the calls handled by a concrete Rule. With this approach, all outbound calls with a predefined destination pattern can be automatically accounted onto the same Campaign.

Destination DN: This is the trunk or hunt-group that will be used to send the outbound call. This is one way of defining the preferred carrier or service provider for the group of calls handled by a concrete Rule.

Destination Vector, if stated, makes the FLEXRouting process applied to the call instead of making it.

Enabled Flag. Activated by default. Allows to manually and temporally inhibiting the rule validity.

Sercom dispone además de funcionalidades típicas como Repositorio de agentes y usuarios, Servicio de Llamadas Salientes, todo ello englobado en una arquitectura multicapa, fácilmente extensible gracias a su diseño basado en plug-ins

SERCOM maintains an activity registry log for each call. The available fields are restricted to the following:

• ContactID
• ExternalRefID
• ContactMediaType
• ContactScope
• ContactStatus
• ContactStatusCause
• ContactResult
• DateTime
• Time_t
• TimeUnit
• TimeQueued
• TimeSpeak
• TimeHold
• TimeAlert
• TimeProgress
• TimeOther
• TimeNull
• TimeTotal
• DomainID
• DomainTag
• ResSubDomainID
• ResSubDomainTag
• CampaignID
• CampaignTag
• VectorID
• VectorTag
• CalendarID
• CalendarDesc
• ValCalendarTag
• OriginalPriority
• FinalPriority
• DialedDestinationTag
• CalledDestinationTag
• SourceTag
• DestinationID
• DestinationDN
• SourceID
• SourceDN
• OriginatorID<7
• OriginatorDN
• FirstAgentID
• FirstAgentLogin
• LastAgentID
• LastAgentLogin
• FirstAttendedID
• FirstAttendedDN
• LastAttendedID
• LastAttendedDN
• FirstEnqueuedID
• FirstEnqueuedDN
• LastEnqueuedID
• LastEnqueuedDN
• FirstAlertingID
• FirstAlertingDN
• LastAlertingID
• LastAlertingDN
• AbandonedID
• AbandonedDN
• QueuedJumps
• AlertedJumps
• OriginalCampaignID
• OriginalCampaignTag

There is also a registry log each time a call reaches an endpoint or changes its status on it. Fields that can by query are as follows:

• Fecha Hora
• Time_t
• DNID
• DNTag
• DNState
• DNStateQualifier
• DNStateCause
• ContactID
• DomainID
• DomainTag

The status of each Agent is always registered in the User Activity log. The generated fields for each entry are:

• DateHour
• Time_t
• Time_Unit
• UserID
• Login
• Name
• UserActivity
• UserActivityQualifier
• UserStationID
• UserStationDN
• DomainID
• DomainTag
• SubDomainID
• SubDomainTag
• UserAcdID
• UserAcdDN