A loyal guest warns of a delay in the reservations mailbox. Three hours later, your system declares him a no-show. Here is how the agents connect the two, and the precise point where your team decides.
Good evening,
My train to Geneva was cancelled this evening. I will only arrive tomorrow morning.
Please keep my booking for tomorrow.
Kind regards,
Marc Favre
The message stays in the reservations mailbox. Nobody reads it.
Arrival deadline reached.
Booking 204 · Marc Favre · two nights · arrival expected today
Status: not arrived
House terms: first night due in case of no-show
| T0 | Message received | 19:15:08 |
| T1 | No-show detected | 22:30:03 |
| T2 | Match found | 22:31:17 |
| T3 | File prepared | 22:33:42 |
| T4 | System stopped | 22:35:06 |
| T5 | Decision validated | 07:08:11 |
| T6 | Reply sent | 07:08:14 |
Three agents worked on the same case, without anyone having to attend to it. The first noted the no-show and re-read your terms. The second found, among what is redirected to it, a message nobody had read. The third checked that the room was free tomorrow and prepared the shifted stay.
Separately, each would have done its job: billing would have billed, the inbox would have let the message sleep, and the hotel would have lost a loyal guest over one night. MYT does not handle events separately. It understands what they change for one another.
Then it stopped. Not because data was missing, but because the decision was not its to make. Whether to charge the first night of a regular who gave notice is for the house to decide. The button refused to send until the house had decided.
And at no point did the system write to Mr Favre. It spoke to your team. The reply left under the hotel's identity, at eight minutes past seven, because someone on your team had decided.
Demonstration with fictional data. The property, the guest and the times are invented for illustration. The engine that produces this work runs in daily production.