Vendor Email Addresses
I like programming (at work) and learning for fun. You'll often find me cooking and working on my house in my spare time.
Imagine you manage Team Awesome at Cool Company. You rely on a third-party vendor, Checkers. They need to send you and your team emails. Let's go through the options, from worst to best.
Individual Emails
Out of convenience, you have your contacts at Checkers email everyone on your team using their individual email address. This is the worst option. Why? If any of those people should no longer receive emails from Checkers, or any additional people should, it's extremely unlikely that you'll be able to get Checkers to update their lists. You're also likely to forget to tell them to update their info, especially if the communication is infrequent. After initial integration, it almost certainly will be.
Team Mailing List
If you give Checkers a team mailing list, teamawesome@coolcompany.com, you get to control who receives emails. Three months later, there's a reorg at Cool Company, and Team Awesome ceases to exist. Oof. This isn't a terrible outcome, but when someone in IT without context decides to delete this team mailing list without context, communication is severed.
Vendor Mailing List
Here's the best option. Make a group email address named for the vendor, checkers@coolcompany.com. That will survive any reorg at your company. You can have emails forward to any individual or group, including teamawesome@coolcompany.com. It's also unlikely to be deleted so long as people know this vendor is still in use. Cool Company or Checkers could still change their name. Still, that happens a whole lot less often than the other two scenarios above.
Summary
When giving email contact info to a vendor, your options are:
Bad:
me@mycompany.comBetter:
myteam@mycompany.comBest:
vendor@mycompany.com
