DevBlog

Summary:

Category:

Link:

Details:

Although we have, for some time, stopped making changes to the existing service, we have just made made a very subtle change which *will* go noticed by a few of our customers.

This subtle change is that we are now dividing customer accounts into US & Global accounts. We've already begun asking new customers which type of account they would like during registration and we've also changed the status of accounts which are obviously orientated around the one of the other.

Once the new service goes live, we'll also offer accounts for other regions as well, and the sole purposes behind these changes are to (1) simplify the service for our users and (2) let us create region-based offerings.

What this means, at present, is that US Accounts can only be used to send & receive SMS in the US (purchasing their credits in USD), whilst Global Accounts are used for messaging operations in other countries (purchasing their credits in GBP).

And, of course, the small minority of customers with operations in both are required to maintain 2 separate accounts.

As mentioned, this change will go unnoticed by most of our customers, but if you have any queries relating to it, then please do not hesitate to ask.

Summary:

Category:

Link:

Details:

Our entire service has been undergoing redevelopment since mid-2006 and we are happy to say that it will be ready for relaunch in the very near future.

The new service facilitates vast improvements in terms of accessibility, usability, competitiveness etc. and will see the launch of an online community and a section dedicated to integration.

Although many of the new features can be considered the produce of customer feedback, we also plan on taking a much more responsive approach to the opinions, complaints and wants of our customers.

As such, whilst the new site is not yet launched, we want to take this opportunity to ask our customer base to give us as much feedback as possible so that we can either cater for the feedback prior to launch or, at least, leave our horizons open for a response some point in the future.

So, if you have any feedback which you feel will make our service better than our competition, please let us know by visiting http://www.tm4bhelp.com/cc.

Summary:

Category:

Link:

Details:

Customers who interact with our service using our main server's IP Address should know that we have moved to a different server in a new hosting environment and that the front-end IP Address has changed.

The new IP Address is 64.38.41.12 and, although the old IP Address will continue to work for a limited period of time (approximately 1 week), such customers are advised to modify their applications immediately. We would also recommend customers to interact with our domain name (i.e. tm4b.com) as opposed to an IP Address.

Customers will also be happy to know that our new hosting environment benefits from significant improvements in:

• Upgraded hardware that should be reflected in performance.
• Physical security for safeguarding our services and data.
• Environmental control features to maximise reliability.
• Redundant systems to maximize connectivity and uptime.

We look forward to continuously improving our services to meet your needs.

Summary:

Category:

Link:

Details:

As of this morning, Email-to-SMS users will have noticed some obvious changes in the way that Email-to-SMS Broadcasts are handled and we'd like to list them here:

The first change is that the delivery reports of ALL Email-to-SMS Broadcasts are being sent back to the email addresses from which they were sent. Previously this was an optional feature, but it has now become a standard.

The second change is that the subject line can now be used to match our broadcast confirmations and delivery reports with your original Email-to-SMS Broadcasts.

Up until now, the subject line was used to provide the TM4B Username and the Email-to-SMS Password. However, with this new development, Email-to-SMS users can now insert the Email-to-SMS Password within the message body and use the subject line to hold something meaningful that can keep our responses in relevant context.

So, if "Mrs Jackson Appointment Reminder" was used as the subject of an Email-to-SMS Broadcast, you can expect our confirmation to look like "Re: Mrs Jackson Appointment Reminder [ACCEPTED]" and a delivery report to look like "Re: Mrs Jackson Appointment Reminder [DELIVRD]".

Email-to-SMS users who wish to make use of this feature no longer need to include the TM4B Username within their broadcasts as only the Email-to-SMS Password is required.

The third change is that, in those cases when an Email-to-SMS Broadcast is rejected, we will provide a full list of reasons for the failure. Previously, one error was sufficient to trigger an error message and prevent the remainder of the Email-to-SMS Broadcast from being processed. However, in those cases when more than one error has existed, you would have been required to fix the first error to find the next and so on. This is no longer the case as all errors will be reported simultaneously.

The fourth change is that we will not be sending error messages in response to those Email-to-SMS Broadcasts in which none of the required values can be found. This is because the "email2sms" address has found its way on the list of email spammers and our mail servers are wasting their resources sending error messages in response to junk mail. Due to the ease with which an Email-to-SMS Broadcast can be made, it is highly unlikely that a real Email-to-SMS User would ever send a message that did not contain any of the required values and we feel that this is a good way to handle those junk emails which get through our spam filters.

The fifth change is that the 'msg' parameter has been renamed 'message' for the sake of verbosity as Email-to-SMS Broadcasts are made by humans and not machines.

The last change is that all of the emails which we send you in response to Email-to-SMS Broadcast have been re-written to be more 'human' and ensure maximum clarity.

All of these changes are geared towards making Email-to-SMS the easiest way for desk staff to send and receive SMS with mobile users and, through your feedback, we look forward to making more improvements in this respect.

Although new screenshots have been uploaded and the "how to" has been changed, the old ways of using "msg" and providing credentials in the subject line can continue for the foreseeable future.

Summary:

Category:

Link:

Details:

Customers will be happy to know that, in addition to Visa Card, we are now accepting payment by MasterCard, Maestro, American Express, Switch, Solo, Delta & Visa Electron.

Furthermore, customers will be even happier to know that the handling fees have been reduced from 5.3% to 3.9%.

We are, however, implementing a Card Verification Program in which customers (wishing to pay using the above-mentioned cards) will have to first verify that they are the owners of the card.

In the long run, we are looking to tie the LowBal Notification system with an automated payment procedure to make sure that customers always maintain a positive credit balance.

Meanwhile, customers that would like to have their cards verified and begin using them for online payments, should contact Sales & Admin.

Summary:

Category:

Link:

Details:

It gives us great sorrow to inform customers that we are no longer offering Long Numbers based in France.

Whilst we offered these numbers to our customers in good faith, it has now come to reality that the up-stream network made these numbers available to us without realising the requirements that increased demand and usage would place on them.

The result of this mis-realisation was that, on two separate occasions in the last 4 months, a total of 3 numbers were terminated prematurely without any notice. On both occasions, we were assured that such an error would not take place again, but a fourth number has again been prematurely terminated.

Although this is a major set-back for us and our customers, we cannot stand to offer a service which is unreliable and we have decided to discontinue formal support of these numbers and approach the French MO market through common short codes.

Although existing French Long Numbers can still be used in this unpredictable situation, customers are advised to discontinue their leases voluntarily in exchange for a refund and preferential prices on our French short code program when it is launched.

Summary:

Category:

Link:

Details:

We would like customers to know that we are discontinuing the "default country code" setting on messages sent through the SMS API.

Although this setting has simplified messaging through the Email to SMS and Web2SMS services, it has confused many SMS API users in their initial development phases.

As usual, the discontinuation is being done in a manner which will prevent client applications from breaking:

• Phase #1: To disallow this feature on accounts in which it is not used.
• Phase #2: To discontinue this feature completely.

Phase #1 has already taken place and Phase #2 is due to take place on Friday 8th Septermber 2006. Customers using this feature on the SMS API should make sure that they have adjusted their applications before the complete discontinuation date of 08/09/2006.

Summary:

Category:

Link:

Details:

In accordance with the rules, regulations and best practices of the mobile messaging industry, inbound numbers (for receiving SMS) and the keywords which they use must now be supplemented with a description of the service which they are being used to provide.

Furthermore, in the case of dedicated numbers, keywords can only be used to provide sub-deriviative services which the dedicated number is registered to provide and, in the case of dedicated keywords, secondary keywords can only be used to provide sub-deriviative services which the dedicated keyword is registered to provide.

Unfortunately, however, this means that we can no longer provide shared access to the 'TM4B' keyword which we have (until now) been giving free access to on various numbers.

Although we are required to immediately discontinue our support for existing message receivers that use the TM4B keyword, we are taking two steps to help our customers adjust their services accordingly:

1. We are delaying the discontinuation of existing TM4B-based message receivers until the last day of August 2006 - this is to protect our customers' services/applications from being 'cut' without alternative measure being adopted.

2. We are offering customers with discounted rates on dedicated keywords on receiving numbers - this is because TM4B-based message receivers were previously offered free-of-charge.

Details relating to the reduced prices can be found in this post and customers with dedicated numbers/keywords allocated to their account will be contacted seperately for descriptions of the services which they are using them to provide.

Summary:

Category:

Link:

Details:

As of today, we are no longer accepting cheque as a method of payment because it has given rise to unexpected and unnecessary delays to the purchase process.

We will, however, be adopting the payment mechanism offered by MoneyBookers.com who do accept cheques.

Summary:

Category:

Link:

Details:

Prior to today, message credits would last for 12 months from the date of purchase, but we have decided that this policy should be discontinued.

Customers will therefore be happy to know that, as of today, message credits will no longer expire.

Summary:

Category:

Link:

Details:

As customers will already know, support for Unicode messaging via Email-to-SMS last week and, in the name of simplicity, the character encoding of Email-to-SMS emails was used to differentiate between Unicode and plain text.

However, as there may be occasions in which a UTF-8 Email-to-SMS message may only contain plain text, treating it as Unicode would cause the maximum character length to be reduced to 70 characters unnecessarily.

So, from now on, in addition to checking the character encoding of the email body, the actual characters of the message will also be checked to see if the SMS needs to be in Unicode or if plain text will suffice.

Customers do not need to make any modifications and this is just an announcement to explain this new future.

Summary:

Category:

Link:

Details:

The first change, as ironic as it may be, is that the 'Discontinuations' category has been discontinued. This is because many modifications also include discontinuations and we believe that combining them together makes more sense. As such the 4 posts which previously formed the Discontinuations section have now been re-filed under Modifications.

The second change, is the introduction of a Promotions category in which we will inform our existing & potential customers of any special offers that may be taking place along with their particulars.

Although the default notification period for the new Promotions category will also be weekly, we are sending a special notification today as our first offer (which is for existing users only) as it is based on a 'first come, first serve' basis and we want all of our customers to have an equal chance of benefitting.

Summary:

Category:

Link:

Details:

For more details, please see the Change Notes.

Summary:

Category:

Link:

Details:

For more details, please see the Change Notes.

Summary:

Category:

Link:

Details:

As announced in late May, we have changed the format of MT broadcastID's and MO smsID's. The new formats are as follows:

• MT SMS - Begin with the 2 letters "MT" followed by 10 digits (e.g. MT0017295001).
• MO SMS - Begin with the 2 letters "MO" followed by 10 digits (e.g. MO0000557958).

Although we had intended on providing an interface through which old smsID's could be converted into new ones, we have not done so on the assumption that customers may not need this.

In any case, we will be keeping the old smsID's in an archived format and any customer requiring a conversion should contact Technical Support.

Summary:

Category:

Link:

Details:

As described here, all three of our Client-API routines are now using both HTTP Post & HTTP Get to communicate with customer servers.

The next three weeks will act as a 'weaning' period to give customers a chance to migrate from the previous use of HTTP Post to the new use of HTTP Get and customers should adopt the use of HTTP Get before Monday June 26th 2006 to avoid any disruption of service.

Any customers experiencing any difficulties with their switch should contact Technical Support.

Summary:

Category:

Link:

Details:

Customers should be aware that we will be changing the type of HTTP request used in our API-Client routines from POST to GET and this will effect the following (HTTP based) routines:

• Delivery report forwarding
• MO Forwarding using a URL
• MO Responding using a URL for content

This change is being made for two reasons. Primarly, it appears that some servers have been configured in such a way that they do not accept HTTP requests using the POST method. Furthermore, to account for developers of all levels, the GET method allows an application to be developed, checked and modifed more easily as our requests can be simulated through the address bar of an internet browser.

To give customers enough time to modify their applications and avoid any disruption of service, we will be implementing this change according to a two step process:

1. From Monday June 5th 2006, our HTTP requests will be made using both methods simultaneously and, from this point, applications will be able to accept the values being passed by either method.
2. From Monday June 26th 2006, our HTTP requests will be made using the GET method only and, by this time, all applications must be able to accept the values passed through this method.

Any questions relating to this change should be forwarded to our technical staff.

Summary:

Category:

Link:

Details:

The Web-to-SMS messaging facility has undergone a service upgrade in which several features have been added, whilst trying to keep it as simple as possible.

Most importantly, it now includes full support for every implementation of long messaging, which can also be de-activated completely. It also includes support for the recent implementation of Unicode in which customers simply need to select the data type value as 'Unicode' and paste their message without performing any conversions.

Furthermore, all of the different settings which apply to Web-to-SMS broadcasts can be pre-saved as defaults and over-ridden, if necessary, during individual broadcast. Those who seldom change their settings can also have the settings hidden by default and make them visible for real-time changes.

Customers wanting to get a better understanding of the different changes should login and simulate a broadcast and any questions should be forwarded to our technical staff.

Summary:

Category:

Link:

Details:

As part of a complete change in direction with regards to our intended launch of a new type of account for US customers, we have changed the names of our existing messaging routes:

• 'First Class' has been renamed 'Global I'.
• 'Business Class' has been renamed 'Global II'.

Although these changes have been incorporated into the new version of our SMS API, which is soon to be released, they do not affect the existing service in any way and customers can continue to submit messages as they have been doing previously.

Our Knowledge Base and DevBlog have already been updated to reflect these changes and customers will be notified well in advance if we decided to discontinue the use of old names/codes completely.

Summary:

Category:

Link:

Details:

As customers should already know, the objective of the Email-to-SMS facility is to provide the fastest & easiest way of submitting messages using nothing other than an email client such as MS Outlook.

This simplicity was previously achieved by defining all mandatory values in the body of the email message using a simple/non-technical lay-out, e.g:

From - OurCompany
To - 4479562**236, 447951292**1
Msg - Don't forget our appointment on Friday at 5pm.
Route - Business

In addition to the default country code, this simplicity has now been enhanced even further by allowing for a default originator and a default messaging route to be pre-saved, thereby reducing the values required to just recipients' numbers and the message body, e.g:

To - 079562**236, 07951292**1
Msg - Don't forget our appointment on Friday at 5pm.

These settings will be of particular use to the larger organisations as less instruction needs to be given to staff and the originator can be pre-set through the main account.

It is also worth noting that the default settings can be over-ridden by including them within the Email-to-SMS message body.

Summary:

Category:

Link:

Details:

As an additional basic setting, a frequently used messaging route can now be saved for use on Web-to-SMS messages.

This new setting should simplify the message-sending process, even if just a little, and we hope that customers are happy to know we do whatever we can to make things easier for them.

This setting has been given its own category within the Knowledge Base which contains tutorials on how to activate and how to de-activate the default messaging route.

Summary:

Category:

Link:

Details:

With a view to simplifying the Email-to-SMS facility as much as possible for human (as opposed to programmatic) use, the ability to send multiple messages to multiple recipients will be discontinued at the end of June.

This feature was originally provided to make the Email-to-SMS facility as functional as possible. However, with the introduction of the SMTP version of our SMS API, the overall theme of the Email-to-SMS facility has been changed to ease & simplicity.

Customers will still be able to send single messages to multiple recipients, as this can be expected of non-programmatic use, and customers who use the Email-to-SMS service to send multiple messages to multiple recipients should migrate to the SMTP version of our SMS API before 1 July 2006.

Summary:

Category:

Link:

Details:

We would like to bring our customer's attention to the fact that we will be changing the format of broadcastID's and smsID's as follows:

1. MT SMS
   The existing format of broadcastID's (i.e. 32 alphanumeric characters) is going to be replaced with the 2 letters "MT" followed by 10 numeric characters (e.g. MT0017295001) and this will therefore effect the smsID's of MT SMS (e.g. MT0017295001-1).
2. MO SMS
   The existing format of MO smsID's (i.e. 32 alphanumeric characters) is going to be replaced with the 2 letters "MO" followed by 10 numeric characters (e.g. MO0017295001).

These changes are due to take place on 7 June 2006 and we are bringing this to the attention of our customers, especially users of our SMS API, because of the way in which customers may be handling/parsing smsID's; applications which would not be able to parse these new formats should be modified before the switch date so that either format is acceptable.

For a temporary period, we will also put in place a "lookup" tool which will return the new equivalent of old smsID's and details of this will follow at the time when the switch has been made.

Summary:

Category:

Link:

Details:

Due to the increasingly fraudulent use of PayPal's payment solution, two changes have been made which relate to the way in which we accept payments made via PayPal. Whilst these measures will not cause any harm to legitimate PayPal users, they will prevent fraudsters from abusing credit cards and PayPal accounts which do not belong to them.

The first is that we are no longer accepting payments from non-Verified PayPal members. Being Verified means that the account holder has confirmed his/her identity with PayPal by following simple steps such as confirming your bank account or posession of a credit card.

The second is that PayPal payments must now be 'authorised' by PayPal members themselves through an authorisation code which is sent to them via email following the 'completion' of a payment.

Non-Verified PayPal members who enjoy the speed and ease with which PayPal payments can be used are kindly requested to visit the PayPal website (www.paypal.com) and have themselves 'verified' as soon as possible. Furthermore, a dedicated section relating to PayPal has been added to the Knowledge Base and taking a few moments to read the following external sources may also be useful:

• Protect Yourself from Fraudulent Emails (PayPal website)
• Phising (Wikipedia - the free encyclopaedia)

We apologise to customers attempting to make a payment via PayPal today; the PayPal option was temporarily disabled whilst these developments were taking place.

Summary:

Category:

Link:

Details:

In preparation for new developments that are about to take place, specifically our new connections with US carriers, the MinBal Notifier has received a few modifications.

The most obvious change is that the MinBal Notifier has been renamed as LowBal Notifier as 'low' is a more suitable/representative word than the word 'minimum' (which suggests the lower end of a scale which cannot be passed).

Also, a few cosmetic changes have been made to its settings page in SMS Online and the LowBal Notifer for existing accounts now has the heading "GBP LowBal Notifier". This is in preparation for a new type of balance for message credits purchased in US Dollars and more information will be provided about this when the new balance goes live.

Lastly, its dedicated section within the Knowledge Base has also been changed to take these new developments into consideration.

Summary:

Category:

Link:

Details:

Following the recent upgrade of our database server, unexpected difficulties were encountered whilst restoring Contact Lists and temporary upload data in which field names contained non-alphabetic characters.

We have therefore added an additional validation rule to the definition of field names which prohibits non-alphabetic characters from being used.

We kindly ask customers to rename the fields of their Contact Lists before the end of June 2006.

Summary:

Category:

Link:

Details:

SMS Dialogue is a tool through which you can monitor communications with your contacts on an individual basis. It combines all of a contact's MO & MT SMS in chronological order along with any information that might be saved about him/her in your Contact Lists.

Following the decision to charge additional fees for the use of our value-added Extensions, SMS Dialogue has undergone a thorough revision:

• It now has a 'full-screen' option which removes the left-hand menu and makes more space for the actual dialogue.
• A lot of information which 'clogged' up the dialogue has been removed and it has been made more cosmetically attractive.
• It now includes the country of the contact, even if he/she has not been saved in a Contact List.
• Clicking on the status of the message now leads to the full overview of the message. If the SMS was an MT, the overview would be a Broadcast Analysis and, if the SMS was an MO, the overview would be the View Message aspect of the inbox.

Summary:

Category:

Link:

Details:

As the online delivery reports page can be used to show all of a single account's delivery reports on-screen, searches can sometimes return 10's and 100's of thousands of delivery reports in one go and presenting these on a single page can obviously take a lot of time.

We have therefore added on-screen pagination for results that exceed 500 in quantity. This means that only 500 delivery reports are shown per page and clickable links pointing to each set of 500 are presented at both the top and bottom of the screen.

It is also worth mentioning that the best way of viewing large quantities of delivery reports is to download them in CSV format and view them offline on your desktop.

Summary:

Category:

Link:

Details:

Whilst we have no control over the time it takes to transfer data from a client to our server, we have been able to reduce the time needed to analyse data and add it to the relevant database.

We've also improved the way in which upload errors are reported. Previously, error codes would be given and errors would have to be 'dug' out using validation rules as a guideline.

But now, this responsibility has been taken on by the new uploading mechanism which presents errors in plain English along with references as to where they exist. For example:

• This file appears to be empty.
• This file has xxx lines too many.
• The field name xxx contains non-alphabetic characters.
• The field name xxx is longer than 50 characters.
• etc.

Although these improvements have been made, clients should still do their best to ensure their data is valid beforehand to save time and frustration, for which information can be found in the File Upload section of the Knowledge Base.

Summary:

Category:

Link:

Details:

In most (if not all) cases, traditional address books restrict users to pre-determined fields like gender and age. However, the requirements of each of our clients differs greatly and, for this reason, we provide our users with the unique ability of defining the structure of their own Contact Lists.

As a part of continuous improvement, we have made a few developments which make the use of Contact Lists faster and easier.

• Previously, users attempting to delete a field name or a delete a contact would be taken onto another page that summarised what was to be deleted along with an "Are you sure?" confirmation message. The confirmation message now shows immediately, without the need to load up an additional page, thereby requiring less time.
• The way in which structures are modified has also been simplified. Each of the different ways in which a structure can be modified (i.e. to rename, add or delete a field) has been separated from the other completely. This should avoid any potential confusion which existed when they were integrated with each other.

We are always keen to hear any suggestions on how improvements can be made. If you have any, then please let us know.

Summary:

Category:

Link:

Details:

As each of our Extensions is quite unique, the only real way to appreciate their value is to actually try them out one-by-one. For this reason, new users are given a trial period in which access to all of the Extensions is free of charge, during which 'LIMITED' is shown as the status besides each extension.

Previously, a customer would be considered as an 'old' customer according to how many MT SMS messages were sent and would no longer have free access to the Extensions at that point. However, we found that one broadcast could easily prevent a customer from ever knowing how useful each extension was and so the way in which customers are considered to be old or new is now determined by date.

The free trial period now lasts 28 days from the date of registration and does not take message-sending into consideration. Furthermore, 'old' customers who missed the chance to trial any of the extensions can request additional trial periods by submitting a support ticket.

Summary:

Category:

Link:

Details:

Whilst many of our clients use the Email-to-SMS service to send MT SMS programmatically, it is actually intended for large organisations that want to provide their staff with the simplest possible means of communicating via SMS.

Previously, multiple recipients had to be separated using the pipe character (i.e. ' | '). For example:

To - 4479562182|4479562123|15043265896|3321235564987

However, the pipe character appears to be considered as 'strange' by many people because it is not commonly used day-to-day life.

So, as part of a few changes intended to make the Email-to-SMS service as simple as possible, recipient numbers can now be separated through the use a of commas (i.e. ' , ') as well. For example:

To - 4479562182,4479562123,15043265896,3321235564987

More can be learned about Email-to-SMS by visiting its dedicated category within the Knowledge Base.

Summary:

Category:

Link:

Details:

Until now, the "Tools" section of SMS Online has been used to contain several value-added applications. However, whilst we have been providing these applications at no extra cost, they have played their part in taxing our resources (e.g. development, support, maintenance, database etc.).

So, in order to maintain, improve and increase such value-added applications, we have been faced with two options:

1. Increase the cost of messaging to cover the cost of these applications.
2. Separate the cost of these applications from the cost of messaging.

In favour of our low-cost messaging policy and to account for customers that do not use these applications, we have decided to discontinue the "Tools" section and create, in its place, a paid-for section called Extensions.

However, in order to continue providing delivery reports free-of-charge, the 'Message Tracking' tool has been converted into a section called 'Delivery Reports' and moved over the 'Send & Receive' section.

Similarly, the 'MinBal' notifier has been moved over to the 'Settings' section so that customers can continue to receive low balance notifications at no extra cost.

Summary:

Category:

Link:

Details:

Following the provision of an extra 10 days, SMS API v1.0 has been discontinued and, from now on, all requests for SMS API v1.0 will be return a message explaining that it has been taken offline and that it has been replaced by v2.0.

As of SMS API v2.0, upgrades will only require slight modifications to requests made and, other than these, customers can continue to use older versions without upgrading.

Summary:

Category:

Link:

Details:

Although we have provided sufficient forewarning and several reminders that SMS API v1.0 was to be discontinued today, our log files show that several applications are still using v1.0 for connectivity.

So, to avoid 'breaking' our customers' applications, the discontinuation date has been pushed forward to January 10, 2006.

Furthermore, SMS API v1.0 has been modified to send out an automated email to the account holder each time a request is made through it - whilst this may cause annoyance, it is to encourage the immediate upgrading to SMS API v2.0.

If you have not already upgraded to SMS API v2.0, please do so immediately.