Got a couple minutes? Looking for WHMCS Notifications Extended feedback here!

whmcsguru

Active member
My apologies... I know this has been posted a couple places, I usually avoid those, but want to seriously get feedback here, as this module has had a good bit of time invested in it lately ;)

For the past few months, I've been embedded in work on a WHMCS notifications module. While coming along nicely, and released, feedback is always a good thing, so if you would be so kind as to take a look at this and give some honest feedback here. What am I missing? What would you like to see here that's not here? What additional hook points, what additional alert points? Functionality?

The idea behind the module:
Email is outdated. Other points of communication should be built into something like this, methods to communicate with clients and staff alike. A module like this provides redundancy and ensures that everything gets delivered as needed. As well, this removes the excuses:
I never got the invoice
or
I was never notified



What current alert methods (aside from email) do you use? What form of communication internally are you using? What am I missing here?

Currently implemented:
  • Pushbullet
  • PUshover
  • Slack
  • Hipchat
  • SMS

On Deck (v 1.3, which should be released next week at the latest)
  • BulkSMS
  • Pushalot
  • Campfire

Hook / Notification points (again, what am I missing here?)

Support tickets:
Staff can receive notifications on new tickets, assigns, client replies (both public and via pm if assigned)
Client can receive notifications on staff replies
New feature - Nags, which can remind via above alert methods about tickets with pending responses at 5 programmable times

Serverping:
I've managed to put together some webhooks which will be included in 1.3 for serverping clients, making notifications just that much easier.

Orders:
Staff can receive notifications on new orders, or when an order is marked as fraudulent (which currently is unacknowledged by WHMCS anywhere else)

Invoices:
Clients and staff can receive notifications on new invoice, payment, creation, late fees, refunds

Services:
Staff can receive notifications of cancellation, suspension, termination, unsuspension
Clients can receive notifications of unsuspension and suspension

Admin only:
More for 'security', admins can be notified when domains, addons, services, or orders are deleted . Since this should happen minimally, ideally no notifications would go out here, again , more of a security thing.
 
From the client side perspective I would still prefer email to keep an archived record of important information. Aside from that and the options you have listed below as alternative options, Text/SMS/Imessage would be my next preference and I think you could add IM options if possible, such as Trillian/Skype/Jabber/GTalk/etc. For those that live on FB and Twitter they may want that option if you can do it. Hope this helps some.
 
Oh, the email option isn't going away. I wouldn't do that.

Text/SMS is already built in via Twilio (which I've really come to love the past couple months) and BulkSMS (which is ok, just nowhere near as good as Twilio). Unfortunately, Apple hasn't released an API for iMessage (that would be awesome)

I thought about an IM based notification setup, but I'm not sure that's going to be possible. Too many protocols, and I've yet to see a reliable API for these.
 
Interesting. I think it would be nice considering Nexmo for SMS notifications as from experience, I did prefer them for SMS (and Twilio for voice).

For invoicing notifications, I think it would be a good idea to have the option of relying on emails at first but if the invoice reminder notifications are ignored then send an SMS notification prior to suspension.

This way it won't get annoying for the customer but they will have the notifications via other channels just in case one was missed preventing a service disruption?
 
Nexmo seems like it's rather doable. I'll add that to the list of stuff ;)

RE: reminders, about to be suspended.... This is where it gets kind of tricky, which is why I put off placing that hook point in. I placed the hook in for invoice generation, because, it's a no brainer. However reminders are a bit different, due to everyone's preferences on suspension, etc. I'm still investigating the possibility of reminder/suspension/termination warnings, just not sure how to approach that yet.
 
Nexmo seems like it's rather doable. I'll add that to the list of stuff ;)

RE: reminders, about to be suspended.... This is where it gets kind of tricky, which is why I put off placing that hook point in. I placed the hook in for invoice generation, because, it's a no brainer. However reminders are a bit different, due to everyone's preferences on suspension, etc. I'm still investigating the possibility of reminder/suspension/termination warnings, just not sure how to approach that yet.

Well I said suspensions in a more general time frame there. It could be anytime between the window of the initial invoice notification and the 3rd reminder really. Anytime after the initial email and before the suspension takes place.

From a customers point of view, it might get a little annoying to see an invoice notification and then an SMS notification every month (not to mention it'll get more costly for the provider when just an email would have been suffice).

Depending on how you hook this in, you might have to look for the cancellation notice flag. Don't want an SMS going out with a product that is scheduled to be cancelled.
 
I thought about an IM based notification setup, but I'm not sure that's going to be possible. Too many protocols, and I've yet to see a reliable API for these.

What about just focusing on one of the popular services then, such as Skype, if they have an API to use? They are probably the most popular option now for IM service.
 
Skype is the more popular service, yes, and once I get 1.3 nailed down,
I'll probably investigate it being used.

From what my preliminary research shows though, this is going to be rather difficult since their API is quite proprietary and uses their own framework. Pretty much everyone uses curl / post at this point for APIs, but it seems, like with everything, Microsoft wants things to be done Microsoft's way.
 
Top