Post Call
The 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.
An example of how customers might use Post Call is to conduct a feedback survey after the call. The caller 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 wants to register to receive some information and the Agent 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 first example of a survey 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. In the second example the voicemail node would be used.
*A-Party clear is detected immediately by the Advanced Services Platform. Any Post Call activity for the B-Party is initiated almost immediately after the A-Party hangs up their phone.
However, B-Party clear can have two adverse effects on service flow if the A-Party has activities to complete post-call.
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 in the DTMF sequence “97272”. The B-Party has approximately one second per digit to enter this sequence – if they fail to key in the sequence in good time, the A and B-Parties will remain connected, and the B-Party will need to restart the sequence. As soon as the sequence has been keyed in successfully, the B-Party’s call will be terminated, and the A-Party Post Call activities will begin.
Where the A-Party is the controlling party
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.
If this is required, the A-Party needs to key the sequence "8-2-7" using their telephone keypad. The A-party has approximately one second per digit to enter the 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.
Both Parties cleared branch
This branch is taken when both parties are no longer present in the call. Only logic-type nodes are permitted off this branch - e.g. Time and Day, Send Post, Send Email, etc.
Summary of branch behaviour
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. Note that the B party needs to provide a DTMF sequence to initiate call termination before physically replacing the receiver, otherwise the A Party may also be disconnected. See *Important note regarding B-party clearing, above.
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.
Last updated
Was this helpful?