1) When people come to me and say "I need someone to build X for me," I usually say "I can help you make sure X gets done right." If the person contacting me isn't especially technical, that means I remove the weight from their shoulders of verifying that they actually got what they paid for when they hire another freelancer/contractor to do the job.

2) Sometimes people already have devs either hired internally or managed externally, and they're having trouble and just need someone to come in and tell them how to get back on track. This might involve some code but it wouldn't actually be my job to write the code, just more of a training thing / someone to call.

3) Sometimes startups with non-technical founders in particular just need guidance on what they should actually be doing with technology. They don't know how it could improve their business, but they do know that they like what my software says it can do, and they're not sure what to do next. Usually these people are trying to compensate for a lack of a technical co-founder.

4) A lot of the time the initial email to me isn't looking for a consultant, and the business may not even have considered the idea; but sometimes especially larger institutions know that they want a consultant with intimate knowledge of the software they're working with. You can't get that by hiring a consulting firm.

Transitioning was easy -- I just started telling people I would do consulting instead of development work when they contacted me. I had intentionally not take development work that involved maintenance agreements for some time (I rarely built complete sites; I just built components or additions to my own open-source software). It also helped that I had spent a lot of time meeting with entrepreneurs and hearing about the businesses of people who had previously hired me. But there is a lot to know about consulting just like there is a lot to know about development and it takes some research and experimenting to deliver good experiences.