We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
us). We have a need for a customer notification system. We have simply
out grown the ability to send emails to our customers manually. We need
to have a better way of notifying our customers of maintenance etc.
We would need to send notifications out to say about 400 customers.
Ideally the system would send an attached PDF. It would be great if this
system were SQL based etc.
Does anyone know of a system that is out there that does this? We have
looked at a few applications (windows based) but integration with
billing etc seems to be a caveat. I have thought of possibly using a
mailing list type approach, but that gets us back to (almost) where we
are today. Any pointers would be greatly appreciated.
We use Mailchimp to relay emails to our customers. They have the ability to
maintain lists of customer addresses, and I believe they have an API for
maintaining the list.
Billing software that caters to smaller web hosts and ISPs like WHMCS
can send out mass mailings, and you can drill down which customers
should receive the email based on the services they have with you.
We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
us). We have a need for a customer notification system. We have simply
out grown the ability to send emails to our customers manually. We need
to have a better way of notifying our customers of maintenance etc.
Seconding the earlier recommendation, mailchimp is a great tool. Good
interface aside, there is strong operational benefit to being able to
issue notices completely "out of band".
We would need to send notifications out to say about 400 customers.
Ideally the system would send an attached PDF [...]
If you're going to do this, please be sure to send a copy of the
notice inline as plain text too. Your customers on smartphones, using
assistive technology, or automatically piping vendor notices into
calendaring/ticketing systems will thank you.
We would need to send notifications out to say about 400 customers.
Ideally the system would send an attached PDF. It would be great if this
system were SQL based etc.
(a) Use ASCII. Using PDF for this is insane.
(b) You're dealing with only 400 customers, yet you want the overhead
and complexity of a SQL-capable database? Do you also engage a fleet
of bulldozers when you want to plant a flower in the back yard?
I have thought of possibly using a
mailing list type approach, but that gets us back to (almost) where we
are today.
Precisely what is wrong with a "mailing list type approach", using
Mailman (which is the best available and what runs this list)? It handles
COI (mandatory for responsible and ethical operation of all mailing lists),
it runs on all varieties of 'nix, it plays nice with MTAs, it deals with
most bounces in a sane fashion, etc.
Yeah please don't use PDF. There is nothing more annoying than getting an email about something important that had a PDF attachment to tell you about the important things. Lowest common denominator!
I used to use mailman for this, but we had a CRM system as well which was database driven. So I write a script to grab the right email addresses from the database every night and populate mailman.
I hate it when businesses think that they will somehow improve my reading experience by bloating up the email, sending attachments, etc. What about if I'm reading email on my phone? In what way does providing the information in a PDF benefit ME?
99.999% of the time there is absolutely no benefit in the attachment. But by pushing customers to open attachments to get the content we are encouraging them to be complacent about opening all attachments, and that's a great way to end up getting infected with malware.
Make sure you have a Very Good Reason for sending content in an attachment. If your plan is to always send the info as a PDF odds are high that you don't have a good reason for doing it this way.
I agree whole heartedly. If the Marketing/Sales folks are stuck up on branding,
I'd explore sending a MIME multipart/alternative with branded HTML and a
plain text version with no degradation of actual content. And keep the whole
thing under 25-30KB total. Creating them is pretty easy with perl MIME::Lite.
Well there isn't anything wrong with the mail list approach, but it is more complicated than sending email to a list of customers. We have several types of services (transport, ss7, managed Noc svc etc). Having the db backend would give us flexibility for future notifications based on type of service etc.
Well we would not be sending the notification in an attachment, but there are times when it would be nice to send a list of circuit ids (exported from billing system as PDF) or some other exported doc to the notification.
Spurious attachments also (like HTML markup, another email worst practice
used only by (a) people who don't know any better and (b) spammers) chew
up bandwidth, which is sadly becoming an increasingly expensive commodity
for everyone using mobile devices. They eat space in mail spools. They
require more resources to be scanned (whether for malware, dubious URLs,
exploits, or anything else).
Nice for WHO? There is absolutely no need to export something as simple as a list of circuit IDs as a pdf. Use plain text. Ditto for the rest of your exported DOCs.
When there are exceptions, when you need to include an image (sparingly, not because marketing thought it was a good idea to bling up all your emails), or a table, send in HTML with plain text. Don't make the recipient start up another program to open an attachment.
