My business partner, Julian, as started a posting on his blog about Business SMS Code of Practice. I'm currently in Melbourne, Australia and unable to make the get together, so I thought it would be worth documenting my thoughts.
I think the key to getting something like this adopted is to just start and get to first draft as soon as possible. Trying to involve too many people in the first drafts is a recipe of the whole processing grinding to a halt and just slowing dowm. Someone also needs to take the lead, which Julian has agreed to.
Once at first draft then I think it should be pushed out to as many people as possible for comments. In the UK this should include the Mobile Data Association. The mobile operators should also be approached but I don't believe their involvement is necessary for publication of the code.
Once the first release has been published, then it's the responsibility of us in the mobile industry to get our clients to adopt this code and get them to promote their adoption to their user base.
Then we hope enough steam has been gathered and it's all been worthwhile ;).
The areas I'd like to see considered are:
- Timing of messages
- Frequency of messages
- Cost of messages
- Validity period of messages
- Unsubscribing from services, if appropriate
- Monitoring of message content
Timing of messages
This is the biggie for consumers. Julian's example of being sent a message at 06:15 AM is unacceptable in the context of that service but might not be in another context. For example, one of our customers, GMSL, runs a service to enable their customers to manage the supply and demand of their gas portfolios. They use SMS to notify of changes 24 x 365, thus any restriction around hours wouldn't be suitable for them.
We could consider 3 timing categories and identify the timing category of the service to the customer in this way.
- Office Hours - 09:00 to 18:00, Monday to Friday, excluding public holidays.
- Extended Hours - 08:00 to 20:00, 365 days a year
- 24 Hours - 24 hours, 365 days a year
Frequency of messages
Another area to cause annoyance to users of the service will be messages coming too frequently or not frequently enough. It might be worth considering a categorisation of service, eg: Frequent, Daily, Weekly, etc but I wonder if that's going to be too prescriptive. We should probably stick to documenting how frequent the messages will be.
Cost of messages
Different services will have different charging agreements with the customers, but customers should be made fully aware of the charges both for receiving and sending messages to the services.
If the provider is using a virtual mobile number to enable customers to send messages in, they need to be sure they understand the charges involved. In the UK, sending to numbers from the non-mainland network operators can cost the customer more. T-Mobile charge their subscribers as if it's a European destination for messages sent to numbers to Manx Telecom, Cable & Wireless Guernsey and Jersey Telecom.
Validity period of messages
Not so sure about this one but it could include some information about the validity of messages, ie how long will the provider attempt to send the message to he subscriber before it is considered expired.
Unsubscribing from services
Being able to unsubscribe from services is a key requirement of consumer services but in the context of some services it may not be relevant.
Consideration should also be given to the cost of unsubscribing. Making messages free to send is possible, our Freetext service supports it, however for practical reasons I don't think it should be a requirement. It could be a recommendation though.
Monitoring of message content
There should be provision in the code for monitoring of the content of messages for acceptable use. In the same ways calls to companies are recorded for "training purposes", the content of messages should be monitored. The code should document that this is a standard part of services.
I look forward to seeing outcome of the first discussion, sorry I can't be there.
No comments:
Post a Comment