This seems different from what discussed before. So both networks have similar issues?
What I mentioned about channels still may apply - check it practically. But if problems comes and go, check connection latency of your connections, If it is in the area >50msec normally, when it comes to 150 msec you'll get timeouts from clients just because too slow communication between ZD and APs. It is usually the reason if links are slow and use old technology (DSL), and almost never on fiber networks. It may be also case if you use provider, which actually outsource last mile and runs some overlay (PPOE or PPTP) over other provider networks and having router somewhere far from the end-user network. If this is a case, you may have problem which can't be resolved without changing ISP or using different solution.
Anyway, the best way is to enable debug on ZD, than, after having this problem, find affected APs IPs and client MACs, download debug file and look for messages related to this APs and clients. This will say what is reason of disconnect (timeouts will be obvious as well as any other specific reasons).
To analyze debug file you need analyzer tool (available for Ruckus partners on support site), or you can open case and ask Ruckus support to look on the file.
Another thing I often have seen -- empty DHCP pool. It happens, when a lot of clients are moving around, but DHCP server has long hold time (7 days, for example). In public places almost any size of DHCP pool can be completely used in just hours. In places with big client number and a lot of moving you want to use 1-2 hours or even less hold time.
In a big shop you can get 256 address pool full in 5 minutes, so you want to use really short hold time and bigger pool...