A topic in every SfB deployment I’m involved in is main number handling, and rightly so. Callers to your organization deserve a first class experience, and that experience needs to also meet your organizations objectives. For example, do you want a caller to first reach a live receptionist and only overflow to an auto attendant, or are your calls best handled by an automated system?

Over the next several posts, I’ll review the organization characteristics and requirements for main numbers, and the features in SfB for main number handling. I’ll then dive deeper into each feature to show how they work and what the benefits and drawbacks of each may be. I’ll then outline how the features can “snap together” to provide a more detailed solution, and give some real-world examples that I’ve seen.

30,000 Feet

A main number is any phone number that reaches your organization, but isn’t assigned to any one particular person or phone. A regular user, Common Area Phone, subscriber access, and conference room phone aren’t main numbers. Main numbers are things like reception, help desks or support lines, team phone numbers, or even things like enterphones/door buzzers.

The beginning is a very good place to start

Jumping in to the technical features of SfB is a terrible place to start this process. Your technology products need to address your business issues, so let’s start with business processes and people.

If you’re migration to SfB from another system

A migration means that you’re already handling your main numbers in some fashion. Document how the number is currently being handled. Review what you’ve documented with the users that are involved with handling calls to the number. This includes anyone who might answer the phone, but also those who receive calls from an Auto-Attendant, for example. Your goal here is ensure that you have accurately and completely captured how things are working today (and not necessarily how they’ll work in SfB)

• If you’ve identified phone numbers, voicemail boxes, departments, recordings or greetings that you don’t know anything about, you will need to ask around. Call those unknown numbers, leave voicemails in those odd looking voice mailboxes and ask people to call you back. I’ve seen one organization that just couldn’t track these down set up bounty-hunter prizes for staff members who solved the mystery of the unknown number. (Some people will do anything for a Starbucks gift card!)
• During this process, be sure to ask stakeholders about any toll-free numbers that might be involved. Typically, a toll-free number is delivered to a regular number at your organization. Make sure you don’t disconnect the regular number, or port it away to a different carrier without also bringing the toll-free number.

Next, review what you’ve discovered and documented. Your current system might be decades old, and may have grown organically and uncontrollably since then. Ask those involved if they like how it functions, or if they’d like to see any changes made. Draw up a new plan based on their input, as if you were deploying a new number – which brings us to the next section…

If you’re deploying a new main number

A net-new number can be easier or more difficult that a migration. It can be easier because there isn’t any legacy baggage of “we’ve always done it this way”. It can be more difficult because sometime people don’t know enough to provide useful input.

Meet with those involved in handling calls to the main number, or receiving calls from it. Establish what their requirements are, and how they would like to see the system work. Again, stay away from technical features – focus on what people want and what the business needs. Draw up the new plan, and review it with those involved.

Designing and Documenting

Whether you’re migrating or deploying net-new, don’t aim for one rigid plan that you’re now going to try to implement in SfB. Instead, capture ideas and concepts like “if reception doesn’t answer within a couple of rings they might be busy, so also ring accounting, then if nobody answers after 30 seconds, go to voicemail”. Whiteboards, post-it notes, and the Office Lens app on your smartphone are your friends here.

You may wind up with multiple plans or ideas for handling some numbers. That’s fine, and maybe even useful as you being to map those requirements to features available.

Mapping Requirements to Technical Features

Now that you have a handle on your current deployment and what the desired functionality is, you can being to examine the technical options for implementing that functionality. As you progress, you may need to rework your desired functionality because of technical limitations, or new ideas that arise when you map your desired functionality to the technical options available. If you have multiple possible plans or ideas for a number,

In the next post, I’ll jump into an overview of the (many!) options within SfB. Stay tuned!