Updates to our Second Round Submission
We allow Codeshare Partners of ACE Airlines to submit offers to frequent flyers via the paid plan of our 3scale API. These are sent out in the passenger's preferred language, via their preferred comms mechanism (as per our previous submission only SMS messages are sent; emails and push notifications are stubbed). The test case we have used is a message that is sent only to those passengers that have not purchased check-in luggage for the connecting flight on XYZ Airlines, warning them that purchasing luggage at the counter will be more expensive than pre-purchasing it online. They are invited to reply with "Yes" / "Oui" / "Ja" (or any equivalent of "Yes" as per their preferred language if they would like to receive pricing for pre-purchasing luggage. If they do so, the Telstra SMS API sends a payload to our newly created node.js API endpoint.
The original process we developed now includes a reusable sub-process that is instantiated for every instance of the multi-instance sub-process in the process in our original submission, receiving the SMS messageID, the passenger details, and the passenger's frequent flyer information. The top-level process does not wait for the reusable sub-process to finish before completing. The new sub-processes wait for the node.js micro-service to receive a signal where the signal reference is the messageID. Thus if we send an SMS to Jim and the response from the SMS API says the messageID is "8EDFFE35A305EA61959701000500BA73" then when node.js sends a signal with signalRef of "8EDFFE35A305EA61959701000500BA73" we know that it is Jim who has replied to our outbound SMS, because Jim's process instance is waiting for that exact signalRef (which was passed in an as input from the calling parent process) and the rest of the process logic is then "activated" by the catching intermediate event signal. We then knowe what Jim's preferred language is, and, having looked up checked-in baggage pricing that is specific to the specific airline (in this case XYZ Airlines) we send the relevant pricing information to Jim by return SMS in Jim's preferred language. This way we help Jim avoid "sticker shock" by getting stung for much higher luggage pricing - a potentially uplifting customer experience for Jim if we help him save money and stay a happy customer of both ACE and XYC. Note that the reusable sub-process that keeps running after its parent process has terminated will itself keep running until the offer (e.g. purchase check-in baggage online) will self-terminate via a timer at the appropriate time (e.g. once the original ACE Airlines flight that connects to the connecting XYC Airlines flight has departed).
We also increased the event-driven messaging to ACE Airlines departments, staff, or related parties. One such innovation is, in response to an event like a gate change, we identify passengers who may require special assistance, such as an unaccompanied minor, or a person with a disability, and let ground staff know that these people might need help getting from the old gate to the new gate, especially if a person with a disability has mobility issues.