App:Travel Assistance Request Operation Center: Difference between revisions

From Kordeus Wiki
Jump to navigation Jump to search
Stefanseiler (talk | contribs)
Stefanseiler (talk | contribs)
No edit summary
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[File:PAX_Operations_Portal_main_process.png|thumb|PAX Operations Portal main process]]It mainly governs the management of [[Travel assistance service request|travel assistance service requests]] in service operation centers, which are by rules defined in the [[service operations flow designer]].
This frontend application for OC staff members supports them to achieve these goals:


== Core process ==
* '''keep overview & priorization''' - intuitively show which  [[Travel assistance service request|travel assistance service requests]] require attention to
The processes delivered in travel assistance service operation centers are always adhering to this process flow:
** '''maintain deadlines''' - deadlines approaching require attention
# '''Creation phase''' - [[Travel assistance service request|Travel assistance service requests]] can be created by passengers (PAX) through [[PAX Portal]] instances. Each of these requests hold a [[Travel word definitions|travel itinerary]] consisting of multiple [[Travel word definitions|travel segments]] and a list of requested [[App:Travel assistance service administration|travel assistance services]].
** '''increase service quality''' - if communication requests of the patient have arrived, a speedy reaction time drives customer happiniess
# '''Asssignment phase''' - The PAX Portal sends the travel assistance service requests to ''travel assistance operation centers''. These operation centers claim responsibility for one or mulitple travel segments of the itinerary.
* '''central data store''' - easily allow accessing all information on a [[travel assistance service request]]
# '''Processing phase''' - From now on, the ''travel assistance operation centers (OC)'' are processing the request and
* '''support decision making''' - when opening a [[travel assistance service request]] immediately see open decisions.
#* may request further information from the PAXregarding the segments and services they were requested
* '''govern service delivery''' - see the service delivery process and track service delivery of the delivery partners.
#* may decide on if the service <u>can be performed</u> or <u>is rejected</u>
* '''collect statistical information''' - during the process information needs to be collected from 3rd party systems.
#* may request a decision by special staff (e.g. doctors) , if the service <u>can be performed</u> or <u>is rejected</u>
# '''Collection phase''' - Once all information was collected and the service was considered performable, it may require money collection. In this phase the OC facilitates the money collection process. After this is performed the service is granted and the OC is monitoring and perfoming tasks to implement the service.
# '''Service delivery phase''' - During this phase the OC monitors the service delivery and performs actions to make sure that everything works out.


== Stakeholders ==
== Screen-Flow ==
Facilitating this process means constant interaction with many parties involved in service checking, service validation and service delivery:


=== Patient ===
* Personal task monitor - This shows to each staff member the tasks to be processed by the team the staff member is in. The team member can take into his/her responsibility or return it and confirm it.
During the whole process, the PAX can use the [[PAX Portal]] to: 
* Current request list - Aside from tasks, sometimes it is good to have an overview on all current requests and their current status. From here the staff member may enter the request and perform actions, even without tasks. This may eventually remove tasks
 
* Request screen - This is the central screen, where the itinerary and requested services are displayed. Only one agent may enter the request screen in edit-mode to avoid parallel processing on a single request. From here:
* file the [[Travel assistance service request|travel assistance service requests]]
** services per segment can be marked as processed
* see the combined status of the all the service requests, segment by segment
** tasks can be filed to delivery partners, patients or internal teams (frontdesk, doctors)
* provide missing information 
** services can be confirmed or rejected
 
** information requests can be sent to patients
=== Delivery partners ===
 
Services are typically not delivered by the operation center (OC) themselves, but by delivery partners. OCs push information and tasks to them within the core process. The delivery partners use a [[PAX Service Delivery Partner Portal]] to:
 
* receive and confirm tasks
* confirm service delivery
* communicate with operation centers


== Related articles ==
== Related articles ==
 
* [[SARA.Core (Special Assistance Request Management Suite)]]
* [[PAX Operations Portal]]
* [[App:Travel assistance service administration]]
* [[App:Travel assistance service administration]]


[[Category:Apps]]
[[Category:Apps]]
__NOTOC__

Latest revision as of 12:25, 22 June 2025

This frontend application for OC staff members supports them to achieve these goals:

  • keep overview & priorization - intuitively show which travel assistance service requests require attention to
    • maintain deadlines - deadlines approaching require attention
    • increase service quality - if communication requests of the patient have arrived, a speedy reaction time drives customer happiniess
  • central data store - easily allow accessing all information on a travel assistance service request
  • support decision making - when opening a travel assistance service request immediately see open decisions.
  • govern service delivery - see the service delivery process and track service delivery of the delivery partners.
  • collect statistical information - during the process information needs to be collected from 3rd party systems.

Screen-Flow

  • Personal task monitor - This shows to each staff member the tasks to be processed by the team the staff member is in. The team member can take into his/her responsibility or return it and confirm it.
  • Current request list - Aside from tasks, sometimes it is good to have an overview on all current requests and their current status. From here the staff member may enter the request and perform actions, even without tasks. This may eventually remove tasks
  • Request screen - This is the central screen, where the itinerary and requested services are displayed. Only one agent may enter the request screen in edit-mode to avoid parallel processing on a single request. From here:
    • services per segment can be marked as processed
    • tasks can be filed to delivery partners, patients or internal teams (frontdesk, doctors)
    • services can be confirmed or rejected
    • information requests can be sent to patients

Related articles