🔁 日本語に切り替える / Switch to Japanese
I still have a lot to say about the LUUP app, but I see light at the end of the tunnel when someone in the LUUP company is willing to listen to 🔗my complaints and concerns. There has been some progress through several updates. So, it was another attempt to share my thoughts when I was unable to return the bike at the port due to the unresponsive app.
The problem lies in its feature that requires us to send the issue report from within the very app where the issue originates, while it is currently ongoing.
It happens a lot, actually, but I rarely report it due to either or both of the following:
- I just can’t because my app is detached from the app server.
- I just can’t because I’m detached from the LUUP app.
But this time I did, somehow.
It keeps telling me “Try again” forever when I’m trying so hard to return the bike. Do I need to try harder? But when you’re rejecting me from accessing your server, how can I “Return and report a ride problem”
To: [Your Name]
(Translated by Google)
This is the LUUP Customer Center.
Thank you very much for using LUUP.
We sincerely apologize for the inconvenience caused by the delay you experienced when trying to return your vehicle.
Because the ride took longer than planned to conclude, we have canceled the 200 yen ride fee.
Depending on your credit card provider, this will be reflected on your statement within 5 to 10 business days. If you cannot confirm the cancellation after 10 business days, please contact your credit card company directly.
We will continue to strive to improve our services and hope for your continued patronage.
Contact Information: LUUP Customer Center
Help Center: https://support.luup.sc/hc/ja
Email: support@luup.co.jp
Hours: 07:00–22:00
Company Website: https://luup.sc/
Emails received outside of business hours will be answered on the next business day.
This email was sent by Luup, Inc. via Zendesk.
(Original Japanese)
■■■(株式会社Luup)2025/12/23 午前8:01 JST ■■■様
LUUPカスタマーセンターです。
平素よりLUUPをご利用いただき、誠にありがとうございます。
この度は返却に時間がかかりましたこと、ご不便をおかけし誠に申し訳ございません。
予定より終了に時間を要したため、ライド料金200円につきましては、課金取り消しさせていただきました。
クレジットカード会社により、5～10営業日でお客様のクレジットカード明細書に反映されます。
10営業日経過後も取り消しが確認できない場合は、お手数ですが、ご利用のクレジットカード会社へお問い合わせください。
今後ともサービス向上に努めてまいりますので、引き続きLUUPをご愛顧いただきますようお願い申し上げます。
お問い合わせ先：LUUPカスタマーセンター
ヘルプセンター：https://support.luup.sc/hc/ja
Mail：support@luup.co.jp
受付時間：07:00-22:00
運営会社：株式会社Luup https://luup.sc/
※営業時間外のメールの返信については翌営業日以降にご返答いたします
本メールは株式会社Luupから送信されています。 配信元: Zendesk[27JEJY-9Y50Y]
Attachments
3:13 PM (1 hour ago)
to LUUPカスタマーセンター
Thank you for your support as always, I appreciate it. I’m not sure I really needed the refund, as your service was overall worth paying for, despite the issues with the app.
By that report, I wanted you to make it make sense to everyone having the same experience with the built-in report form within the very app where the ongoing issues originated. More precisely, it goes like this:
When finally reaching the screen with the unresponsive “Return and take a photo“ button at the end of all other struggles with the unresponsive processes, it’s always accompanied by another bad boy sitting right above, saying “Return and report a ride problem”.
Maybe this is not the first time seeing it, but a situation makes regular stuff look different, and people might think, “Well, should I press the ‘report’ button instead of the ‘end’ one? It can immediately help me out of the situation, or will it just create another loading icon? Or even worse, it can take me several steps back. Hmm…let’s do it and see what happens next!
So, this is how I got here. And I can imagine there are so many people you never hear from about this. Things would be different if given a separate channel for reporting issues that is located outside the app and has guaranteed access even in those conditions, typically, like something that runs on a browser.
Regards,
It’s highly expected to see some development shortly for this specific issue, as there are easy “solutions” for it, like changing the page layout or replacing/refining the report form. However, I don’t expect to see the fundamental solution any time soon, even though it’s obvious what it would look like.
Yes, it’s obvious. The root cause of the app’s disastrous performance, especially during LUUP’s busy hours, is the overloaded server traffic, mostly due to the persistent, unintended, and UNNECESSARY accesses by the massive numbers of users, such as loading the port location map, looking up the status of vehicles/ports in the given area. They are mildly big data as a whole, which counts up to approximately 5K-20K ports and 20K-100K vehicles across the nation. If you were to observe every single unit’s real-time status, the total amount of network traffic would be like watching a livestream video in low-middle resolution. Do you need it as a user? Of course, no. You only need to get a bike at point A, ride it, and return it to point B.
But most of you would notice your phone’s unusual behavior from the moment you click on the turquoise LUUP icon. It casually initiates aimless map lookup for detailed information of vehicles, ports, or whatever had been set as the default screen stuff in the previous session, which I’m not sure what it actually is, as I sometimes see random crazy stuff, such as the whole continent of Australia or Africa.
The typical “normal” one would be an available vehicle map within a 2 km radius of your current location, but is it really “normal”? When an individual user from a wide variety of people lives each different life and makes different use of LUUP, there is no appropriate initial screen stuff considered “normal” IMAO. But my phone thinks differently. He thinks, “Okay, it’s a no-brainer”, and just routinely does this for the sake of filling the screen. While getting no user input, it continuously generates purposeless “normal” screen updates as I walk, take a train, or even drive on a highway.
Now it’s time to get done with my real task, such as printing a receipt or returning a bike at the destination port. You might think it’s that simple, a couple of clicks in 15 seconds are enough to finish, which has nothing to do with 100 Mbit/s networking. In reality, my phone is already struggling to deal with the overloaded network traffic in the crowded area Shibuya. He is still such a dedicated, hard-working servant who is always up and ready to show me where and which vehicle I can grab among 3,000 candidates waiting for me at 300 ports within a 2 km radius. So he carefully watches every single motion my fingers make, detects any slightest touch on the screen, and immediately checks up on all their status to redraw the map.
This is why it takes 150 seconds, not 15 seconds, just to return a bike. You see at least a couple of the error messages saying “Try again”. So you click on it, he resends your GPS, re-looks up on the server to validate the port and bike’s status, and then fails somewhere in the process…Repeat from step 1…
The important thing here is that all your unintended server accesses are disrupting not only your own task, but also all other users’ tasks online. You unexpectedly became one of them through the app’s arbitrary network access. No one wants to be part of it, but the app just forces you to be.
At some point, you may also realize how much it has financially cost you, seeing how many GB your phone consumed just for a few rides on LUUP. Take a look at my phone’s monthly traffic report below. I’m not a super heavy LUUP user, but the extra bill for my phone costs more than the LUUP’s monthly subscription fee.
I assume 90% of it could be eliminated by optimizing the app’s outrageously lax bandwidth usage.
＃LUUP ＃BikeSharingServices ＃eSchooterTokyo