Ideally, sure, you'd want actual users to have a chance to test the new functionality out. But thats not always feasable/practical, and the effort in doing so doesnt always pay off. I agree that beta testing doesnt always produce the information you need in such a situation. Whats often most helpful for small changes is to have a quick single round of 'testing' by beta testers to ensure there are no glaring problems.
If you are comfortable with the internal testing, what you can do is make the beta available for those who want it for a short period. On your website, or wherever is appropriate. You may get some feedback on it, maybe not (depends on the features and size/nature of the user base). After a short 'open beta', unless major problems are reported, send it out the door.
If your user base allows, perhaps build a small mailing list of users who'd be interested in trying beta builds. That can get a beta build into the hands of a few customers just to ensure there arent any show stoppers you might have missed. It doesnt have to be a formal beta process.
Another option here is to separate your development channels. If you have an auto-updater built into your software, make an option for the user to be notified of beta updates. Put a beta update online, and when you are satisfied with it, mark it as a release so that everyone else will get notified of the update. This way you do a 'soft' roll out, with a subset of the users getting the update, so if there is a problem, only 10% of your users are affected, not 100%.