Without getting into all the flavors of WAN links, it helps to keep in mind, vs. typical LANs, that you're often working with much less bandwidth (usually due to cost), 100 to 1,000 times less isn't uncommon; your working with much more latency, 10 to 50 times more isn't uncommon; and often users consider LAN performance the network norm. The last point is why even if you install DS3s, user's might still consider the line very, very slow (with luck maybe without one or two verys).
Instead of simple rules for how many users might be supported per "X" bandwidth, which often works well on LANs, for WANs, it can be of benefit to analyze what you're users are doing, and various ways to satisfy that need (with attendant costs).
For instance, you mention users are browsing the web, if a large proportion is Internet, instead of clogging a dedicated corporate link with that traffic, a local inexpensive Internet connection (e.g. DSL, cable) might be of benefit.
You also mention users checking mail. Perhaps a local mail server might be of benefit.
For other WAN traffic, perhaps a WAN accelerator WAFS type product might be of benefit.
For some other services, perhaps you could replicate some servers.
For some, or all, of above, and especially perhaps with the upcoming data mirroring, a sophisticated QoS model could be of benefit.
The goal is to find the best combination that supports your network requirements at the least CAPEX/OPEX costs. Often with WAN, more bandwidth alone might not meet this criteria, as it often does on the LAN. (Don't misunderstand, there are times WANs require bandwidth increases, but often there are other methods, at less cost, to provide the same or better benefits.)
