Need to be able to offer timed promotions


#1

We need to be able to offer time limited promotions.

For example, offer a rate that is $30 for the first year and then the regular price after that. The system would also need to notify the client a month or two prior to their promotion ending and their rate will be increasing.

The system does offer the ability to change the price of a service, but there is no way to put in a time period for that promotional rate.


#2

You would use a package with an expiring discount to do this. There’s no notification, but it solves the pricing issue - that’s the intent of expiring services.


#3

That’s what we’ve been doing only to find out that the system doesn’t calculate or report properly.

The system figures the taxes and fees based on the original plan amount, which is obviously higher. Then it reports the income from the higher service plan. So, in addition to incorrectly applying taxes and fees, the system also throws off reports for determining revenue for franchise calculations. It says that the revenue from data service for that city was $X. When in fact it was much less. We then have to pay the higher amount because that’s how much the system says that we made from that service.


#4

If you put the same taxes on the discount, it will calculate the tax credit, which is reflected in the reports.


#5

We already have enough services just to figure out which service is taxed for which locality. Creating a discount for each locality further complicates billing.

We have to create City1 Service A, City2 Service A, County 1 Service A, etc. Then there’s Service B, and on and on. Next is the Packages for City A, B, County A, etc.

Do you see how complicated just one service and one package is? Now to create those for credits too.

We also incur a bill from our support company every time a discount ends. “Why is my bill higher?” Please figure out a way to show the remaining credits and send an email 30, 60, and 90 days out.


#6

You don’t need to do that. You would just create a ‘City’ tax and use geotaxes to apply it properly. You shouldn’t have services per locality.

Hit up support if you need help with this… it should be easily doable.


#7

I just sent over a note.

Looking at it, I don’t see how it could possibly work properly. We’ll see.


#8

Confirmed with support.

The Geocoding doesn’t work. It fails to take into consideration that there’s a difference between the city limits and the mail delivery area with the same name. The city, county, and zip can be the same for both inside and outside of the city limits.

As a CLEC, we need to be able to properly do reporting and some other things. It looks like there a some minor changes (I know that any programing change is major) that could be implemented to group people properly.

I tried to explain this to the support staff, but I don’t they they fully understand.

As more and more WISPs get into ROW services like fiber, their needs for traditional telco reporting and tracking will require more control. It’s important that any proposed solution works when scaled. A couple of proposed solutions sounded plausible. And they were until you scaled it to several locations. If the solution works with 1 scenario, but not with 10 or 10,000, it’s not a solution.


#9

This is why we implemented Avalara - it’s what all of our telecom and large ISP customers are using and it works very well.


#10

We all shouldn’t have to pay thousands of dollars per year additional for basic billing and reporting functions.

It could easily be implemented similar to the other options, such as the one where it asks if it’s a voice service or has an upload download limit.

For example, you could add:
In service setup - Checkbox - Franchise service? Could be Y/N or get fancy with options.

In customer address (because addresses are what determine taxes and fees) - Franchise ledger code, franchise location code, etc.

Lastly, we create the franchise location/ledger/etc codes that would then break out the report.

Somewhere in here too, you could fix the Geotax piece to get the correct franchise amount based on the code.

See, don’t need to spend thousands for external companies to solve simple problems. Just need to look at it like the other things that are already getting done in the system.


#11

If you’re willing to do all that manual labor to link things up, then you can essentially already do this by just making services that match franchises and put customers in groups by franchise. The intent of integrations for things like Avalara is to create a scalable solution that doesn’t require human intervention or thought for implementing and imposing business logic. Having to flag every customer by franchise in the current system is not something that is a safe and repeatable solution for a business with hundreds of employees. We generally always look for ways to let you define business logic that removes the ability for error when a call center is the one adding and updating your customers.

In V2 with the serviceable address concept, you could remove all ability for regular users to create addresses and flag them in that way, but that doesn’t really fit into the V1 methodology.

The reality is that the core of the product is not built for dealing with things like franchise requirements currently - you can work around it with some of the methods I’ve mentioned, but it might just be that Sonar is not a good fit for what you’re trying to do with it.