The attitude inheirant in such an approach is usually pretty obvious to the client, who may perceive you as being argumentative and combative. I've met a few people who tell me they manage to withstand all change requests by categorizing them all as add-on work that will be considered and implemented after the current development iteration is complete. This is less managing change than it is postponing change, and can result in clients choosing to hire someone else for their next job, especially if change requests seem eminently reasonable and minor. Many people don't have a process at all. They may do some of the things outlined earlier, or they may simply agree to do everything, and live to regret it.
Weekly meetings are no good if no one shows up.
You need the people who can decide to fund your project for 40 more hours to get a piece of functionality into the system involved and making that decision. I think you'll find my five questions can form a strong core for your scope or change management process. Whether you choose to hold weekly meetings, communicate the request electronically, or handle the request on the spot - or make up your own process, these five questions can help you make sure that you are prepared to manage your product's scope. They'll be funded, scheduled, or otherwise compensated for. That's the best kind of change.