The problem with internal users is that they don't really exist in the sense that "decision makers" would like them to. There are people that use your application and people that do not use your application. That said people are separated by a hallway instead of an interstate does not make them particularly special. When you are asked to design for internal users you are usually being asked to skimp on these features:
- Administrative interfaces.
- Ease of use enhancements.
Please, please, PLEASE avoid the temptation to cut drastically on the above features. They don't have to have the spit and polish you would give to a client facing application (a misspelled word here or there won't kill anybody) but these features should exist, they should make sense, and they should be useable without people having to email you every 3 months asking if you can make one little change here or there.
Without an administrative interface, you will need to remember what all the tables and files in your application are responsible for. You will need to completely memorize the internal structure of the application, or you will need to wade through piles of code every time somebody has a request. Neither situation is good. Those brain cells are better spent remembering good places to eat lunch, and the time you save by not designing a proper administrative interface will be spent every time somebody has a question about making a configuration change. Either spend a little time and effort now, or a lot later. Multiple times. Until you either get fed up and kill somebody, quit, or write the administrative interface anyway.
Anything you put in front of users should be intuitive. Granted in most cases internal users, or users in any niche market, can be expected to have a level of sophisitication that is above average, but if interfaces don't make sense, the application isn't serving its purpose. Computers and applications are supposed to be tools that make people's lives easier, not puzzles. At least, not in this case.
Documentation is critical. Even if it is nothing more than an email briefly explaining the application's feature set and how to use the main features. You don't need a complete manual detailing why you chose the lovely magenta headers, but you should have something that users, and you, can refer to that explains what the application does and how it does it. For this sort of documenation I prefer a wiki. It can be a pain to go update the documentation every time something changes, but you will be kicking yourself when, 8 months after deployment, somebody comes down the hall with a question that you don't remember the answer to. Instead of taking 15 minutes to skim through some docs, you will be taking hours going through an old code base you barely remember.
I've found this particularly true for instances where I am writing small one-off applications, excel macros, python scripts, etc. that are written to solve a particular issue. There are stretches where I crank out 3 or 4 of these a week, and then many months later somebody asks me for a program that performs some function I've already taken care of, or they ask about using something they haven't touched in a while and they've deleted the email that contains the directions. If you write many small utilities, at some point you will start losing track of what they all do. Simple to use interfaces with clear documentation will save your users from some angst and will save you from wasting time either going through old code or, worse, reinventing your own wheel.