Dynamic Dynamic Keyword Pool Number Allocation


#1

It’s really silly how the dynamic keyword number pool requires extensive manual work to adjust the number pool size:

  1. Take peak hourly visitors divided by 4 - requires finding this in Google Analytics, which is not clearly show in the help files
  2. If your number is greater than 50 numbers required, contact support
  3. Support says it may be too high, need to go back to Analytics to check the average website visitor duration
  4. What about the average call length duration?
  5. If still greater than 50, CallRail support needs to manually allocate
  6. If set too high at first, CallRail’s system won’t let you downgrade. Need to contact support again
  7. Remember to check back when your peak visitor count changes and you’re busy handling you’re growing business and CallRail isn’t… you gotta adjust it manually yourself to ensure it’s working right.

All of this manual calculating and adjusting of the dynamic number pool, ironically, could be handled… dynamically by the system :robot:

If this makes sense to you, give it your Vote.

CC: @bryan


#2

Hey @nickth! Thanks for the feedback! Always great to hear, and also for following the appropriate channels for the feature request!

I am a member of the CallRail Support team, and wanted to reach out and see if I could be of assistance outside of the feature request? To fulfill any immediate concerns?

Let me know, by submitting a ticket to support.callrail.com while logged into your account!

Happy to help.


#3

Hi @nickth - Thanks for the request. I appreciate you taking the time to offer us some useful feedback.

I can certainly understand your feeling like there must be an easier way to solve this number pool size question, and I agree it would be nice to have our system configure all of it automatically so you don’t even have to think about it. Unfortunately there are a few scenarios that make this totally-dynamic approach not as straightforward, which led us to the approach we have today. Part of our mission is to provide a straightforward solution, which includes the way we bill our customers. A switch to automated/dynamic pool sizes would create unexpected changes in invoices. It’s good feedback to hear that this may be a more appealing approach (pay per visitor instead of per number?), but it would require us to re-think how we offer straightforward pricing.

The rule of thumb is to have enough numbers in your pool so that everyone that visits your site will see a different number. That’s what allows our attribution to remain accurate. So we suggest looking at peak hours of activity (in a tool like Google Analytics) so that you can get a sense for how many customers may be on your site at a time. On the flip side, we want to help customers save money - and avoid surprising invoices - by not having far more numbers than necessary. So our support team may suggest taking things into account like site duration and call duration as a way to find the pool size that’s just right. Our goal is to help you make an informed decision so that you have the right size pool to achieve accurate attribution.

I empathize with your wishes to avoid having to contact support to manage your account. We’re always looking for ways to make our app more self-serve. However, we’ve found that it’s very rare that anyone would need more than 50 numbers in a pool.


#4

The billing/pricing reasoning doesn’t make sense, given the fact that per minute charge total changes on a monthly basis, too.

Think of dynamic phone number allocation in the same way extra minutes are added beyond the baseline package allocation.

It doesn’t require a pay per visitor approach.

Even as more or less numbers are needed, CallRail could simply reallocate those numbers to other customers experiencing a spike in traffic.

Our traffic numbers are changing constantly, based on seasonality, ad budgets, competition, website changes, etc. And our call length numbers may change as new call reps come and go, get trained differently, etc. Why can’t our systems change to keep up, too? It’s unreasonable to expect CallRail customers to manually micro-manage the dynamic phone number pool.


#5

I agree that the idea of dynamically adjusted keyword pool sizes is appealing! I think that it offers enough of a benefit to warrant consideration of a change /some flexibility in billing.

With “dynamic keyword pools” as an optional feature, customers could simply be charged for the maximum number of phone numbers that they used during a billing period. However, I can see how in some cases a pay per visitor model would be more economical (ie, very spiky call volume).

I would caution against the reallocating of numbers to other customers experiencing spikes in traffic. People tend to save numbers in their phones, write them down, or go through their recent calls to redial a business. Switching numbers between companies so often could cause a whole slew of issues. We tend to keep numbers active for a period of time in our accounts after we stop using them (and also port over old call tracking numbers if transitioning from another call tracking account) to maintain the call forwarding and monitor the call volume until it dies off enough to comfortably release the number.


#6

Thanks for jumping in with feedback @Morgan_Jarvis! Again, it’s helpful to hear that this is appealing in some cases.

Again, this is something we’ve looked into before, and would love to figure out, but it poses some tough challenges. For the same reasons you mentioned @Morgan_Jarvis, we’re very careful to assign numbers for the exclusive use of a single customer, and to not un-assign those without explicit request from the customer. This is important to a large portion of our customer base, so we’d be reluctant to implement something that dynamically recycles numbers from your pool to another customer. We’re also reluctant to automatically reduce pool sizes for customers, since this may cause numbers that customers have previously saved to stop working. (This may be more important to certain customers/industries than others, but something we have to consider across the board).

So in order for us to be able to allot a dynamic keyword pool size for customers, we’d have to make those numbers exclusively YOURS for some time frame, which under our current billing structure would add a charge per number. (I think many customers would be fine with the fluctuation in invoices to have a dynamic pool size, but I also think that many would not like an unexpected rise in invoice due to some unforeseen traffic spike.)

But, your feedback on this would be helpful:

  1. Is it okay that numbers a customer previously called may stop working in the future?
  2. How long would you need those to be guaranteed to call your business before recycling and reducing the pool size?

I these tradeoffs would potentially vary from customer to customer, which again make it hard to find a solution that fits everyone. But I agree it would be great to find a solution to this that solves the problem for a high percentage.


#7

Hi @bryan - thanks for your response!

  1. I think yes, but only once we are reasonably sure that the phone number has stopped receiving call volume.

  2. It honestly depends on the business. We have had cases where a business’s employees found a tracking number online, thought it was the business number and began using it on print materials, business cards, etc. We were unaware that they were using that tracking numbers on print materials, and when we stopped using it online and disabled the number, all of a sudden those calls could not get through to the business . This is obviously a bad situation from an attribution standpoint as well, but stuff like that happens. Old numbers for a business such as a dog boarding facility could also still receive volume for a long period of time from repeat customers who saved the number in their phone during their first interaction. Because of this, I think the only way to responsibly know when it is safe to release a number is to have a system in place that monitors call volume on each number and marks them as eligible for release if no phone calls come in over a predetermined period of time.