Name not number on SMS send window
This post is to solicit comment on an enhancement we would like.
If a customer has multiple SMS enabled phone numbers, and you click the SMS button in the left panel, then the SMS create window has a pull-down to allow you to choose which number to send the SMS to.
In Hong Kong, it is highly likely that a customer will have multiple SMS enabled phone numbers (husband, wife, domestic helper) and it is quite normal for one to want to SMS all of these on different occasions. However, since just the phone numbers are shown on the SMS create window, in order to SMS the required person, one cannot just press the SMS button in the left panel, but rather must first ensure that the Customers|Information screen is selected, then click the contacts tab, then click the required contact, then click the SMS button.
If, on the SMS Create window, instead of showing the phone numbers, the Phone Name was displayed, then it would be easy to select the required SMS number, and one could do this from any of the Customer and Patient workspace screens.
After a delay for any comments I will ask Tim A to spec and price this enhancement.
Regards, Tim G
Re: Name not number on SMS send window
OpenVPMS already has a similar sort of functionality like this. We set up contacts for a customer with additional contact names by adding the contact's name after the phone number thus (this is where you could write name, partner, helper, etc):
Then when we want to send an SMS, the number with the name in brackets appear in, and can be selected from the drop down box, thus:
OpenVPMS strips off anything that's not the number, so that the SMS goes out ok.
HTH.
Yuri.
Re: Name not number on SMS send window
To be fair the stripping from the SMS was implemented because people wrote details like (sue) after numbers to identify them - and it was necessary to strip them to ensure backwards compatibility. In a international sense it isnt sustainable at all, because the regex to strip out anything NOT a phone number might not work in other languages and countries.
Going forward I would assume that change the Phone Contacts Name field should be the standardized norm for identifying specifics for an individual contact
In fact the updates to the Summary window that is proposed does exactly that and in a similar fashion could easily be transposed to the SMS send window.
Re: Name not number on SMS send window
Yuri - I am afraid that I agree with Ben - one should not use a kludge to get around a problem.
ie Problem = "can't tell who number is for"; kludged solution="add stuff to number because it will be stripped out". The proper solution is of course to display the contents of the name field.
Furthermore the kludge will not work for us - we control the format of the phone number field to be "Format must be 9999 9999 or international numbers like +44-123-467-8901 or +61 2 1234 5678 or anything starting ??" [The latter was included purely to enable bad data to be retained during the conversion from RxWorks] Hence a number like "1234 5678 (Sue)" cannot be entered.
Regards, Tim G
Re: Name not number on SMS send window
Tim, Ben
I have no issue with a kludge-free solution to the problem, and I concede the kludge works only in Australia. I was pointing out a work-around that exists now.
Must admit though, I'm not looking forward to going through the client list to move "Sue" et al from the phone number to her own description field.
Yuri.
Re: Name not number on SMS send window
Yuri pretty sure it would take only a an hour or two to construct a mysql regex query to move those names to the Name value field.
Re: Name not number on SMS send window
I am throwing my hat in with TimG and Ben. We have trained staff to enter names in the Phone Contacts Name Field. This way doing doing things will likely be better in the long term so we would prefer this solution.
Re: Name not number on SMS send window
I think Ben's changes to the customer summary display the contact name field after the number e.g:
It would make sense to retain this format for the SMS window.
It would also be helpful to those users that: