Helping a shared-device operator resolve paid-but-not-started orders

The operator brought exceptions from its existing system

This client already operated its own payment and control systems. Some paying users reported that a machine had not started, while the client’s support staff could see only a successful payment.

The operator commissioned YIIIOT to investigate the gap between payment notification and device execution and give each exception a traceable handling path.

Support lead at the client shared-device operator · Client conversation · illustrative

A paying user shows support the payment record. The system says the order succeeded, but it still cannot establish whether the service happened.

We followed an order from payment to operation

YIIIOT compared payment, notification, commands and device action, defining separate evidence for successful payment and completed service.

We also worked with the client’s support staff on finding the order, machine and handling status from information supplied by the paying user.

YIIIOT connected order records with device feedback

We aligned order and device references, added firmware acknowledgements and cloud exception records, and revised timeout, repeated-notification and restart handling.

Cancellation, compensation and refund steps followed rules agreed by the client and its payment provider. Staff could see the current status and next action.

The client could explain and complete exception handling

In this example, YIIIOT resolved the disconnect between the client’s payment records and device execution. After the agreed exception checks, operators could trace the evidence and continue the appropriate handling.

We walked through an exception with the client and handed over versions, state definitions and diagnostic references. Its support and technical staff could use the same records when users reported a problem.