I have worked on teams as a tester and worked on teams as a tool developer. Stuart talked about the transition so I won't talk more about that, but I think I can add some helpful information on what to expect and what you can focus on in your new role.
You are going to be a development team producing products with real customers. The sooner you wrap your head around that and start acting like a real product team, the easier this will be for your customers. Make sure that you treat your tools as products, create a schedule for fixing and deploying those tools, create high quality documentation for those tools, if you haven't already - decide how you will handle support. Do not underestimate support costs and time spent in bug fixes, even with a handful of customers it can end up eating away a lot of your time, especially if you have no process surrounding it. If you have multiple team members, you may even consider having one of them "on point" or tier 1 for support for a week at a time to try to avoid randomizing people and allowing them to do their normal work. One helpful thing is to have an archive of questions and answers, whether that is a forum or a searchable DL, etc, it is very important to have this so that you are not answering the same questions over and over again.
Be prepared to say no and to justify your priorities. Now that you have multiple customers, they are going to have their own agendas and will push to get their high impacting issues fixed. A good way to help with this is to get representatives from each of your customer teams to meet periodically and be involved in the planning process, give you feedback and bring info from your team back to their respective teams. This will allow them to get consensus on which bugs and features your team should focus on. Keep in mind though that fixes to infrastructure that may have small impact on your customers but a large impact on your team still need to have priority and you need to be the advocate for those changes and back them up with data around why they are important and why they should take precedence over whatever other features your customers may want.
Lastly, it's easy to fall into a mode where you create tools for everything your customers would ever want and before you know it you're suffering from feature bloat. You've got a bunch of disconnected tools that do "everything" but they are confusing, hard to find, hard to figure out, etc. Your team needs to be adamant about quality. The same as in a real product team, it is better for your team to create and maintain a few very effective elegantly written and maintained tools than to have a bunch of poorly written and maintained "quick fix" tools.
Hopefully this is useful information. Good luck :-).