One Number, One Big Problem

If you have one public toll free number you advertise broadly, you may have a problem. It’s something we’ve seen several times in the past. Giving the client one number to call solves their problem of deciding which number to call you at. The problem of taking that call and getting it to the right place now becomes yours. If you only ever have one type of call, then you can probably figure it out pretty quickly. Otherwise, you’re going to need help from your Interactive Voice Response (IVR) builder.

Your inbound IVR, or dialplan, has to have the intelligence built in to route the call correctly, possibly with user input. Using a dialplan builder, there are two primary ways to do this:

  1. Play the options for your caller and let them choose via a menu
  2. Branch on known data.

Play the options and let them choose

This is the most common IVR type most people are aware of. They hear an audio file, enter a digit at the prompt, and continue through the call flow. This may involve another menu further down the line. An auto attendant is usually enough to provide this functionality. That’s not to say that you can’t do call pre-processing and already have done some routing.

Here the important aspects are making sure that you have an audible, good quality prompt that clearly lets people know their options. It’s also best if you don’t present too many options at once. You can always subdivide categories later with another menu.

Branch on known data

This is a bit more complicated. It may look like there’s not a lot of known data to branch on. You may have more information than you realize, however. You might also be able to get the client to supply you with more. Things like caller ID and the number they dialed are known right away. You can ask them to enter their postal code (if your jurisdiction has numeric postal codes), or an account number. That can lead you to more information you may already have. Here’s an example:

A national brand has an advertising campaign with one toll free number. Everybody interested in their services uses that number. Repeat customers also use that number to call in.

  1. The caller ID is matched against existing client records.
  2. If a client record is matched, its data is associated with the call, and any postal code information is set in the dialplan
  3. If the postal code is not currently known, the client is prompted for it.
  4. An internal database is consulted to check to see who services that postal code. Some postal codes are handled by the company itself, and the others are handled by franchisees.
  5. If the postal code is handled by a franchisee, the call is transferred to the number on record for that franchisee. If the call is not answered within 30 seconds, the call drops into a queue for such calls.
  6. If the postal code is handled by the company, calls can go into one queue for new clients, or if it’s repeat business, into another queue for those callers.

In the dialplan builder, we would use a component to associate the call with known contacts, then a branch, then a user prompt, then a simple lookup component, then another branch, then transfer or queue components.

Visual Dialplan builder results

In the example shown, you can see how the call comes in and flows through the dialplan. The postal code is retrieved either in the “Call List Data” component, or the “DTMF” block where we request the data from the caller. We can then look up the postal code in the “Inbound Call Router” which simply pulls a row of data from a lookup table. In this case, it specifies a phone number if it’s a franchisee. Once we’ve collected these items, it’s a simple matter of routing the call where it needs to go.