This has been driving my boss and me nuts. We want XTime to be the one delivering these messages. We were contracted with OneCommand and they could handle it, but we just couldn't trust OneCommand to keep things clean. We had too many customers complaining about various messages going out, so we decided it best to save the money and stop the complaints.....doesn't seemed to have hurt business either.
The way I figure it, is you need to have whichever system your people are actually working out of delivering any type of messaging. There are 2 reasons for this:
1. Database consistency - your people can make quick changes on the fly instead of relying on someone to change the DMS and pray that the change makes it to the next vendor
2. Contact History - there is nothing worse than a customer getting something automatic and they come in saying "you told me my car was ready" and the employee is a deer in the headlights....that's when technology really fails
In a perfect service world I would:
Screw the DMS - contract with some sort of CRM company and make sure my data is mine in that contract - if I ever leave that CRM company for any reason I am taking my data with me. Then I'd have my people living inside the CRM. The CRM would prompt the service writer to ask the customer whether that customer wanted to be notified by email,
cell phone, text message, or by some other method (be really cool if you could drop them a line on faceBook or Twitter too). Then it would prompt for the second best way to contact
today. Then, as various things are posted to the ticket the service CRM would have a 'translate to English' feature that would take "RO#45879 PO# 8945667 5/6/2009" and translate that into a text / email / tweet of "We ordered a part for your car and it should be here on May 6th - will keep you updated as things progress".
And that's just a small taste of what I'm thinking.

who is going to build it?