LUUP app has a serious problem


So I needed to say something to the support center. Now I’m regretting that it shouldn’t have been this aggressive and long, thogh.

I appreciate your support, as always.
Regarding the previous issue, those suggestions were, however, notoriously futile and unfeasible in the road transportation environment. All I needed to know at the moment was whether it was down for everyone or just me, and if the latter, maybe I’d better forget about LUUP for the day and move on, then later I could somehow fix my things if needed. That’s why I first asked a plain yes-no question.

After all, my LUUP app magically recovered without fixing, as I expected. Your boss may or may not allow you to publicly admit that’s a pretty common phenomenon, but I’ve experienced it occurring from time to time. They are so occasional and sporadic a type of issue that they are usually gone in a few hours, and people just tolerate, forget, and even choose not to talk about the root cause. But this time, I decided to share my thoughts about the topic.

It’s obvious to me that the root problem has been almost visibly there whenever I see the app screen, even though I’m not an expert. I don’t think the LUUP company is trying to keep it invisible or trying not to make it visible. But you can’t stay neutral that way if you keep it alive 24/7 in a healthy condition. It doesn’t necessarily have to be crystal-clear, but there has to be public access to information about the server’s real-time status in some form, such as:

(1) Official announcements made public, typically automated online.
(2) Distinctive real-time notification of server response failure on the app.

Putting (1) aside for today, I would give some details about (2). It’s all about the app’s fundamental flaw, which is critically worsening the issue.
The app has the UI object (image-1) called a spinning cursor, which is supposed to indicate that the machine is busy processing the task.

It is supposed to inform users what is going on behind the screen, with a realistic expectation of the response delay. However, if you look closer, you’ll notice its features are so different from the norm. It’s indeed telling sorry-I’m-busy-ish something, but the condition for its appearance/disappearance is unpredictably inconsistent. That’s the main reason why it’s not helping users but rather helping to create all the mess and confusing people.

The app gets stuck either with or without the spinning cursor, showing either a partially or wholly unchanged screen. Users are left in oblivion, given zero info about whether the last several commands are being ignored, finished, or in the queue waiting to be processed. If the last, will the delay be either two more seconds or minutes, or possibly halted?

The criteria of “acceptable delay” and “process failure” differ among the app products, but they should be consistent so that users can see what they can/cannot do next. Should I re-tap it, tap another button, wait for another minute, restart the app, or reboot the phone? Who knows, let alone notice further details such as whether the wait is due to a prolonged internal process, a network connection failure, or a delayed server response.

Just a few seconds of delayed response is enough to create an exponential detrimental interaction. Once the environment gets involved in it, you can easily waste 20 minutes just for getting a bike reservation. Needless to say, it also occurs during the charged period, which means you can’t unpause or return the bike while paying the fee. But it’s nothing compared to the curfew that keeps you from going to school, work, or even the toilet.

image-2: Screenshot_20251023-011925.png

BTW, there is another UI object (image-2) that indicates the app’s unresponsiveness. It looks like trying to explain what the disruptor is, but it turns out 100% of the time it says “NO INTERNET CONNECTION – bluh bluh…” which blames OUR side of the network issues, even if no other apps on the same phone have a network issue. I’ve never seen it tell something like “Our server is currently slowing down due to the traffic overload, sorry for the inconvenience”. Instead of that, it only says “If…bluh bluh…stable connection does not resolve the issue, please contact LUUP / Retry / Contact Us”, which is translated as “It’s already out of our hands, oops, YOUR hands. Bye-bye”

Tbh, I can’t trust all other error messages or trouble reports, if any, on your app. Neither do your template replies from the support center.

Best Wishes,


█ █(株式会社Luup)

2025/10/24 午後5:58 JST

█ █様

LUUPカスタマーセンターです。
ご返信いただきありがとうございます。

この度はご迷惑をおかけし申し訳ございませんでした。

ご報告いただいたアプリのUI設計の問題、エラー表示の問題等については、担当部署に連携し今後のサービス改善に活かしてまいる所存でございます。

ご迷惑をおかけし大変恐縮ではございますが、また何かございましたらご連絡いただけますと幸いです。
今後ともLUUPをご愛顧くださいますようお願いいたします。


お問い合わせ先:LUUPカスタマーセンター
ヘルプセンター:https://support.luup.sc/hc/ja
Mail:support@luup.co.jp
受付時間:07:00-22:00
運営会社:株式会社Luup https://luup.sc/
※営業時間外のメールの返信については翌営業日以降にご返答いたします

#LUUP #BikeSharing #ループ #バイクシェアリング #電動キックボード


Leave a Reply

Your email address will not be published. Required fields are marked *