Post Call
Last updated
Was this helpful?
Last updated
Was this helpful?
Post Call node allows activity to continue on the call after either the A-Party (calling), B-Party (receiving) or both Parties have ended the call. Post Call is an ‘entry point’ node in a similar way to the Start node – i.e. it is not preceded by another node. Its execution is triggered by a clear down from either the A or B Parties in the same way a Start node’s execution is triggered by a call arriving (i.e. the A-Party) on the Advanced Services platform. The Post Call Node will need to exist in the same Service as the original call. An example of how customers might use Post Call is to conduct a feedback survey after a call. The caller (A-party) could leave feedback on the Customer Service they have received during the call. The Agent* (B-party) would hang up and the Caller (A-party) would then be connected to an IVR menu where they are asked a series of questions; they respond by pressing the relevant numbers on their telephone keypad (e.g. How helpful was the agent on a scale of 1-5). Another example might be that the Caller (A-party) wants to register to receive some information and the Agent (B-party) asks them to leave their contact details, the Agent* hangs up and the Caller is passed through to a voicemail to leave their contact details. Note: the Post Call Node is used in conjunction with other nodes – the survey example above would require the DTMF Capture node to record the keypad numbers pressed and the Send Post Node would be used to send the responses to the customer’s database (external to the Advance Service platform). In the second example the Voicemail node would be used.
However, B-Party clear may have two adverse effects on the call flow if the A-Party has activities to complete post-call. It's worth testing these scenarios on any new services first before deciding to use any of the options listed below.
Firstly, B-Party clear may in fact clear both legs immediately and the A-Party will be terminated before its Post Call activities can begin.
Secondly, B-Party clear may not be detected until up to two minutes after the B-Party has replaced their receiver. This means the A-party will be listening to silence for up to two minutes before their Post Call activities can begin.
In order to avoid these two scenarios, the B-Party has to register their intention to clear down before replacing their receiver by keying DTMF # using their telephone keypad. The B-Party’s call will be terminated, and the A-Party Post Call activities will begin.
If the A-Party is in control of the call (e.g. they are a call centre placing outbound calls), they may need to terminate the B-Party leg in order to complete some post call activity. Again - it's worth testing any new services to check that a straightforward B-Party cleardown without any preceding DTMF doesn't cause any issues. If this is required, the A-Party needs to key either *, 6 or the sequence "8-2-7" using their telephone keypad. The A-party has approximately one second per digit to enter the 827 sequence - if they fail to key in the sequence in good time, the A and B-Parties will remain connected, and the A-Party will need to restart the sequence. The longer DTMF sequence is used to avoid the system picking up rogue audio that mimics DTMF * or 6 and thereby terminating the call early, although recent long term analyses have suggested that * and 6 are reliable as a means of terminating the B Party. See also: node (which describes how to define the DTMF Controlling Party).
This branch is taken when no parties remain in the call. Only logic-type nodes are permitted off this branch - e.g. Time and Day, Send Post, Send Email, etc.
The behaviour of a service with the Post Call node present in the call flow is as follows, based on the various combinations of active branches: 1: "A Party Cleared" branch connected When the A party clears, the nodes off this branch will be available for the B party to interact with. Note that outdial-type nodes such as "Deliver Call" are not available for execution off this branch. 2: "B Party Cleared" branch connected When the B party clears, the nodes off this branch will be available for the A party to interact with. It is possible to place a new outbound call by connecting nodes such as Deliver Call off the "B Party Cleared" branch. Be aware that this new B-Party will trigger the Post Call node again ("B Party Cleared" branch) when it clears. Note that the B party may need (see comments above) to provide a DTMF sequence to initiate call termination before physically replacing the receiver, otherwise the A Party may also be disconnected. 3: "Both Parties Cleared" branch connected This branch will be taken once both parties have cleared. Note that no interactive-type nodes can be executed off this branch (as there are no parties present to interact with them!) - logic-only nodes are permitted - i.e. Time and Day nodes, Send Post, Set Variable, etc. 4: "A Party Cleared" and "B Party Cleared" branches connected If the A Party clears first, the "A Party Cleared" branch will be taken - see 1: "A Party Cleared" above for expected behaviour. When the B Party clears, the "B Party Cleared" branch will NOT be taken, as there is no A Party remaining in the call to interact with the service. If the B Party clears first, the "B Party Cleared" branch will be taken - see 2: "B Party Cleared" above for expected behaviour. When the A Party clears, the "A Party Cleared" branch will NOT be taken, as there is no B Party remaining in the call to interact with the service. 5: "A Party Cleared" and "Both Parties Cleared" branches connected If the A Party clears first, the "A Party Cleared" branch will be taken - see 1: "A Party Cleared" above for expected behaviour. When the B Party clears, the "Both Parties Cleared" branch will be taken - see 3: "Both Parties Cleared" above for expected behaviour. If the B Party clears first, the service will wait for the A Party to clear, then the "Both Parties Cleared" branch will be taken. Note that the "A Party Cleared" branch is not taken in this scenario. 6: "B Party Cleared" and "Both Parties Cleared" branches connected If the B Party clears first, the "B Party Cleared" branch will be taken - see 2: "B Party Cleared" above for expected behaviour. When the A Party clears, the "Both Parties Cleared" branch will be taken - see 3: "Both Parties Cleared" above for expected behaviour. If the A Party clears first, the service will wait for the B Party to clear, then the "Both Parties Cleared" branch will be taken. Note that the "B Party Cleared" branch is not taken in this scenario. 7: "A Party Cleared", "B Party Cleared" and "Both Parties Cleared" branches connected If the A Party clears first, the "A Party Cleared" branch will be taken - see 1: "A Party Cleared" above for expected behaviour. When the B Party clears, the "Both Parties Cleared" branch will be taken - see 3: "Both Parties Cleared" above for expected behaviour. If the B Party clears first, the "B Party Cleared branch will be taken - see 1: "B Party Cleared" above for expected behaviour. When the A Party clears, the "Both Parties Cleared" branch will be taken - see 3: "Both Parties Cleared" above for expected behaviour. For calls that only ever consist of the A Party (i.e. the B Party never existed because either they didn't answer during an outdial, or because the call flow includes only Audio nodes or Menu nodes for example, and does not attempt any kind of outdial), then only the "Both Parties Cleared" branch would be taken - if it's connected to further (logic) nodes. The "A Party Cleared" branch is not taken in this scenario.