Changing Service Pricing in Sonar: Best Practices
- Our Products & Services
- Getting Started
- Accounts
- Communication
- Billing
- Companies
- Financial
- Integrations
- Inventory
- Jobs
- Mapping
- Misc.
- Monitoring
- Purchase Orders
- Release Notes
- Sonar Billing
- Voice
- Reporting
- Security
- sonarPay
- Ticketing
- Working With the Sonar Team & Additional Resources
- System
- Networking
Table of Contents
Raising prices is a normal process. Rising infrastructure costs, equipment costs, and backhaul costs all affect your bottom line. These costs need to be considered when billing your subscribers. As a result, cost reevaluation might require a price increase of some or all subscriber services. Deploying these increases could influence the relationship with your subscribers, so knowing your options and minimizing disruptions is of the utmost importance.
Managing Service Pricing
There are two approaches you can take when increasing the price of services offered in your Sonar instance:
- Increasing the price for new subscribers only
- Increasing prices for all subscribers universally
Generally speaking, limiting price increases to new subscribers is far simpler. Limiting the change in this way minimizes the burden of notification, reduces call volume from current subscribers, and still benefits your bottom line. However, it's still worth noting how you can accomplish either or both of these methods.
Increasing Pricing For New Subscribers
When increasing prices for new subscribers, the easiest approach is by disabling the old service, leaving it active on existing subscribers and converting it into a legacy service, then creating a new service.
- Head to Settings → Billing → Services & Packages and Disable the old service.

- On the same page, create a new service with the updated pricing. It can reuse the same name as the previous service, as disabling the old service will prevent it from being selected.
Alternative Method For New Subscribers
Rather than deactivating the service, an alternative approach relies on Price Overrides for existing subscribers. This allows you to modify the service directly, without needing to deactivate, rename, and recreate.
- Apply a Price Override to each account that currently subscribes to the service that is being updated.
- This can be done one at a time, or programmatically with the GraphQL API. Depending on the size of your subscriber base, using the API is highly recommended.
mutation priceOverride($input: UpdateAccountServiceMutationInput) {
updateAccountService(input: $input, id: XXX) {
id
account_id
service_id
quantity
price_override
price_override_reason
name_override
}
}
{
"input": {
"quantity": 1,
"price_override": 9000,
"price_override_reason": "Price Override Reason",
"name_override": "Name Override"
}
}
- Update the price of the service from Settings → Billing → Services & Packages. The next customer that subscribes to this service will be charged the new price, while legacy subscriptions will maintain the overridden price until they change their service to something else.
Increasing Prices For All Subscribers
Increasing prices for all subscribers is comparatively straightforward, although it should not be done without first notifying your subscribers and your front-line staff of this change.
- Communicate the upcoming price change to your subscribers.
- Depending on the size of your subscriber base, you could notify them on an individual basis. However, it is usually best to leverage a Mass Message, which allows you to email all your subscriber's based on their service.

- Increase the price of the Service in your instance settings. This will charge the increased price to subscribers with this service on any billing runs, starting the next day.
When you change the Service Price, you cannot future date the change. Ensure that the price change is only done on the day listed in the notification sent to subscribers.