Line Intelligence Reporting Updates
In this release, we have made a number of updates to our reporting tables for messaging. These updates were to provide more transparency in message reporting, specifically around Blasts and use of contact lists to send messages at scale.
We have added a Billed column to usage reports that indicate if the row of data represents an item that counts toward billing or not
The items that will now show up in various reports (Blast graphs, message usage, etc.) that are not technically messages but are now included in reporting (specifically blasts) to provide clarity on the numbers of contacts vs number of messages actually sent.
Opted Out status - When our system knows in advance that a contact included in a Blast or scheduled message is opted out, we do not even enqueue a message. While this protects the client and consumer and prevents them from getting billed for those messages, it was confusing because those items did not used to show up in Blast reports or message usage....because they were not messages. We now have a way to indicate when these instances occur to align the numbers but indicate that it was not a billable message.
In a similar situation, with the newly created TextEnabled vs. NonTextEnabled status for contact phone numbers, we follow the same pattern. If we know, through our Line Intelligence feature, that a contact's phone number is a landline or a type that will not receive messages, we will not enqueue a message. Just like opt-outs, we will display these in the reporting and graphs for clarity, but they are marked as not billed because they were never actually messages.
To accomplish this, we had to update a number of places where the action of send message occurs, so we can properly record the activity in our reporting tables.
NOTE: Clients may ask what the Billed column is in reports.
TRUE = It was a message that we enqueued and sent to the carrier (regardless of the status that came back from the carrier). These are billed messages.
FALSE = The item was not billed because it was never enqueued or sent to the carrier. It's presence in reporting is to accurately indicate the number of people the client attempted to send messages to but were not even attempted due to the scenarios described above.
CRUDy | Bulk Account Creation & Bandwidth Carrier Tooling
As we continue to progress through carrier migrations to get clients off of Zipwhip, our team is developing tooling to make the process achievable for the sheer volume of work we have given our client and line counts. In this release, we have created:
Bulk Account Creation Utility
This is a new utility inside of CRUDy that will allow our internal team to bulk create v2 client accounts with the appropriate settings and permissions. This will help as a step in the process of getting clients moved from v1 Zipwhip Portal and those still on Meevo's older integration (roughly 800 clients). Instead of creating the accounts individually through the UI, the team can batch them an import them into the system.
Bandwidth SubAccount Creation Utility
Another step in the process of migration involves account and line setup within the carrier's themselves. We have already built tooling for Twilio who we will likely use for TFN numbers, but for 10DLC we are moving most of our lines to Bandwidth. This utility will allow our team to batch up client accounts that need to be set up in Bandwidth, and import them into CRUDy. The tool will then interact with Bandwidth's APIs to create the subaccounts and all other supporting pieces to fully set up a client account.
The next step is for us to create the Bandwidth tool that will support the bulk creation of lines and the hosting requests with dynamically generated LOAs (Letters of Authorization).
Public API | Add and Remove Contact from Contact List
We have added two new endpoints:
Add a contact to a contact list
Remove a contact to a contact list
Improved Handling of Irregular Bandwidth File Attachment Types
As we have more and more clients on Bandwidth, we are seeing a wider range of use cases of people sending various things over SMS/MMS. Since all carriers handle things differently, we identified an improvement we could make in our Bandwidth integration to better handle certain attachment file types.
We created additional logging so we could capture more information on what is being sent to us by Bandwidth, which allowed us to implement a more comprehensive attachment storage solution. We now handle .bin files and .smil files more reliabily and evaluate the file headers in addition to the passed in file type extension to determine how best to store.
Nice CXone Updates
Nice is deprecating their existing method of authenticating with their platform in the next two months. In this release, we updated how we authenticate with their system to adhere to their new, preferred approach. This will prevent any loss of functionality or disruption in services.
Additionally, as we continue to see our traffic and concurrency session load increase on Nice, we addressed some concurrency errors we were seeing and improved our session handling.