I recently helped a small wireless ISP get started, and one of the first things we did was put together a management application. It's grown to be moderately large, but a lot of the functionality required can be constructed from various free sources. My client is chugging away nicely with a Java-based (server-side) system, although it could have been written in any one of a large number of languages - Java was convenient for the available skill-set in the company [never overlook the value of using an environment with which the customer is already skilled!]. The Seam+Hibernate stack provides a very quick development path for most of the CRUD [Create/Read/Update/Delete] functionality that forms the backbone of any data-driven app - but it could just as easily be Access, or (insert favorite ORM here). We found a few commercial systems that could do all of this, but they typically cost more than putting this together ourselves - however, that's partly a function of who you have available.
The key to getting the project off the ground, in use, and genuinely useful was to identify the various areas that are essential - and automate them as building blocks within a framework. You're already used to Access+Excel+manual legwork, so you don't need to start with an amazing UI (although it is a good idea to come up with one that doesn't make the eyes bleed) - identify areas to automate (starting with the biggest pain points) and gradually reduce the pain as you can afford to do so. Also, don't be afraid to use various Free/Open Source packages to help out with sections!
The important chunks for my client (and probably for other ISPs) were:
* Customer database. This acts as the core for a lot of the rest of the system; database (and UI) for customers, their addresses and billing information, account history, etc. Includes tables linking to inventory to indicate what devices they have activated and the details (including billing plan, etc.)
* Inventory system. Lists CPEs, with status, location, ownership info and history. Linked back to the customer database, to make it easy to say "Johnny has this CPE, on that plan". This ended up growing lots of historical options for reporting, but those aren't really essential.
* Activation. This was the biggie for us. When a customer (optionally a new customer) is "activated" with a CPE/plan/etc. (a wizard helps you pick), it adds the appropriate history items and invokes scripts that setup the account in RADIUS and LDAP servers. This is the obvious place to include every step you need - but you can start as simple as "email tells you what to do" while you automate the steps.
* Deactivation. Suspending customers (typically for non-payment), handling CPE returns, etc. You can probably live without this immediately, but it is really nice to have.
* Billing. The first few iterations made CSV files for Quickbooks - that should be fine to get started. The most recent handles credit card payments, etc.
There's also a lot of management niceties, and these were integrated back into the main portal for convenience:
* Cacti for graphing various bits of the network, notably throughput and latency across the network. Very useful for planning.
* Nagios for monitoring the network and paging us when something isn't responding.
As it grows, you'll doubtless end up with a bunch of esoteric scripts also. We even have one that periodically uses an SSH session to log into various access points and records who is online in each sector, what their signal strength is like, and any de-registration events that have occurred. That highlights the biggest pitfall: it is really easy to get excited and try to program in the kitchen sink. If you don't focus on small/modular at the core, you'll end up with a mess - fast. We try to keep the core small, and then have the core UI link into various other tools as we create them.