The expression “Dwell Time Extend” is used to refer to the period during a transaction when the cashier / attendant (or even the customer in the case of Self-checkout (SCO) tills) is checking through a basket of items prior to payment. The display of the question during this time has the advantage that it does not prolong the payment transaction.
In most Point of Sale (POS) systems, there are events that are generated when certain actions are performed by either the cashier or the customer. Normally these are not passed on to the payment application because they are not relevant to it, and they may not be “published” outside the POS application at all. However if they are accessible by the TruRating application then they may be used to invoked to pass more detailed transaction (basket data, discounts & promotions)and to trigger TruRating questions outside of the payment process.
With the Dwell Time Extend question scenario, TruModule will be configured to begin the TruRating process at the start of a transaction (determined within TruModule) or when prompted by TruService after receipt of one of the specified POS events. When TruModule receives the event to indicate that scanning is complete and tendering is about to start (EndTilling) then it will give the customer additional time to rate by persisting the display of the question for a number of seconds as defined by TruService when the question was provided. Tendering or other acivities will be held up for this short period until either the customer Rates, Skips or a timeout occurs. Once any of these actions takes place, payment commences. The additional time is typically kept short - typically 5-10 seconds, but the exact period of Dwell Time Extend (i.e. time out) is defined by TruService and configurable centrally.
Note that the Dwell Time Extend scenario can be supported by a number of different design patterns. Notably, TruModule may be implemented in the POS, middleware or the payment application, each of which is likely to obtain the POS events from a different source:
|TruModule location||POS event source|
|POS application||Internal within the application|
|Payment application||POS interface must already support similar events or be enhanced to accept new event messages. The POS application may also need enhancement to generate these messages.|
|Middleware||A middleware component may also receive event messages published from the POS application, either directly - or indirectly by piggy backing on an existing interface. Alternatively it may detect what is happening in the POS by monitoring device activity and inferring the POS events.|
In the example shown below TruModule has been implemented as part of the Payment Application with support for POS events. TruModule could also be implemented as part of the POS application or as a piece of middleware that sits between the POS application and the Payment application. The actual implementation will depend upon the capabilities of the existing applications.
A question at Dwell Time Extend is visible on the payment device while the basket is being checked out. Once checkout completes the question is removed, to allow a card payment to be processed.
The sequence of events and messages for this scenario is shown in the following UML diagrams:
In the above diagrams, a cashier (or in a self-service environment, this may also be the customer) will scan a product. This will cause a message to be generated from the POS that will be captured by TruModule. How this message is captured is variable, depending on what is available from the POS system. If the POS system has an interface that publishes these events, it may be possible to insert a proxy that captures and forwards them to TruModule.
The first digram shows the flow based on the customer providing a rating (or skipping) while the basket scanning/checkout process is ongoing. The second diagram shows how following the completion of scanning the cancellation of the rating question is delayed for a configured number of seconds to allow the customer more time to rate. If they don’t rate within this period then the rating question is cleared.
TruModule will expect to have an access to the PED (requiring an appropriate firmware level), generally via the Payment application, during the time that it asks the TruRating Question.
The customer and operator journey for rating at Dwell Time Extend (ie during basket checkout) is summarised in the following table:
|1||Customer approaches point of service with basket / goods to purchase||PED is idle or displaying the advertising loop|
|2||Operator starts transaction by scanning or in another way adding first item to basket|
|3||Rating question is selected||Next question in sequence is selected. A question may not be asked based on configuration. If no question is selected, then PED status does not change|
|4||Rating question is displayed on the PED||Customer invited to respond 0-9 or Clear to skip. If customer provides a rating or skip before basket scanning is completed, then they receive a confirmation message via the PED “Thanks for Rating”’ or “Sorry you Didn’t rate”|
|5||Operator continues scanning/adding transaction items from customer’s basket||Scanning of basket is not slowed down or disrupted by the rating activity – it’s done in parallel|
|6||Operator finishes adding items to transaction. Total is available and POS initiates the tendering process (this varies between POS)|
|7||If rating question is still active (i.e. rating or skip not given by customer) then rating question is cancelled and PED returned to idle state||The cancelation of the rating question is delayed for a (configurable) number of seconds following completion of the scanning to give the customer more time to rate (Dwell Time Extend)|
|8||Operator continues tendering as normal. This could be cash, card, voucher etc.|
|9||TruRating receipt text is included on the customer’s receipt|