CONSIDERATION

WITH BNS Enterprise SMS SOFTWARE 

WITHOUT BNS Enterprise SMS SOFTWARE

Where is the solution deployed or provided.

The BNS solution is fully deployed in the customer’s cloud tenancy on a Windows Server VM.  It also uses the customer’s SQL Server in the customer’s cloud tenancy. No data other than the message and the destination mobile is sent to a certified SMS service provider.

Most solutions are offered by SMS Service providers who either want a customer to store data in their SaaS service or utilise their proprietary REST API to lock the customer into their service.

Data security.

The BNS solution is fully deployed in the customer’s cloud tenancy.  Therefore, the databases are secured within the appropriate zone in the customer’s cloud tenancy.

Depending on the solution offered by a service provider, some data is typically required to be stored at the service provider.

Security and data breach.

The BNS solution adheres to the Australian Federal Government email protective marking standards.  Any email based applications or users have to nominated an allowed protective marking such as SEC=UNOFFICIAL for the message to be allowed to the public SMS network. Allowable classifications can be configured in the BNS solution.    

Allowing Applications direct access to a SMS Service provider comes with risk.     Email networks with classification controls would need to consider the risk of data spillage over SMS.   

Audit and compliance.

All inbound and outbound SMS transactions are recorded in SQL Server in the customer’s own cloud tenancy.  No data is sent to the service provider other than the recipient mobile number and the actual message to be transmitted to the recipient.

Applications would need to implement this themselves.

Security of inbound SMS.

The BNS solution can block inbound SMS for specific 2 way capable SMS Numbers assigned to the SMS platform.

Where the customer allows inbound SMS from the public networks the BNS solution can remove URLs before the SMS message is composed as an Email and sent to the customer’s email platform.  In the case of Office 365 Exchange online, the software uses SMTP\TLS to SMTP.Office365.com.

Applications would need to implement this themselves.

Development effort.

Simple internal email & SQL API.  SMS Platform then handles the transmission to one or more SMS Service providers.

Typically, a SMS Service provider will want you to use their REST API to lock you into their service.  Using REST specific to a SMS Service provider is more complex than using simple email or SQL API calls.

Duplication of development effort for each application.

For large volume (other than simple broadcasts) the SQL API provides a simple method of sending and receiving SMS messages. Applications do not interface direct to a service provider which minimises exposure and data leakage risks.

Each Application you have has to re-invent the wheel and handle all of the considerations and issues associated with REST to a single SMS Service provider.

SMS Service provider lock-in.

Not locked into any specific provider.

Locked in because your applications would be hard coding to their REST API.

SMS Service provider price negotiation.

As you are not locked into any specific provider, you can negotiate price per SMS knowing that it would be possible to switch providers.

Limited ability to negotiate price.   Moving to another provider would be costly as EVERY APPLICATION would need to be modified to use the new provider’s REST API.

System Administration effort.

Onboarding applications is managed using a management console included with the software.  Management of applications and users is controlled knowing exactly what how applications and users send messages.

A system administrator would need to invent some mechanism to track and control which applications are using which credentials and services relating to a service provider including the sender ID of an SMS and any 2-way SMS numbers.

Cost centre controls and billing.

Cost centres are defined in the management console included with the software.  For each SMS sent, the cost centre is recorded in a database of all transactions.

The SMS Service provider cannot provide this information as it has no knowledge of your internal use cases.

Backup SMS Service provider.

This capability is built into the SMS platform.

Applications would have to orchestrate their own backup and duplicate effort and duplicate code sections for automatic failover and implement the other service provider’s REST API calls structures.

Automatic disclaimers.

Supported.

Applications would need to implement this themselves.

Application software bug and duplicates.

Any duplicate message requests to the same mobile number in a 24 hour window are automatically filtered to avoid potential huge SMS bills if there is a logic error at the application layer.

SMS Service providers generally do not filter duplicate messages.

Message release time windows.

This is supported based on the application sender identifier.  A release window is optional for any application.  This avoids batch processed SMS being sent to a recipient at 3am in the morning (gateway time).

Applications would need to implement this themselves.

Multi-company\brand or business unit name.

Supported.

Applications would need to implement this themselves.

Metadata automatically captured and stored for analytics.

Supported.

Applications would need to implement this themselves.

Simple SMS Broadcast using a text file containing thousands of recipients.

Supported for end users or applications.

Applications would need to implement this themselves.

Out of the box analytics.

Supported with base templates for PowerBI and Tableau.  Provides data insights into the use of SMS and cost centre analysis.  Meta data from applications is stored in the customer’s cloud tenancy in SQL Server.   

A customer would need to implement this themselves.

Auto responders to incoming SMS.

Supported if required.

Applications would need to implement this themselves.