Things to know before you start installing FreePBX
-
Before you go starting to install FreePBX (or really any PBX), you need to know a few things.
Without knowing all of this, it is highly likely that you will end up wasting money. Maybe directly by purchasing more than you need for some service or another, or just in the time spent doing things multiple times.
- Number of DID – How many phone numbers do they have
- Inbound Call Flow – How are inbound calls handled.
- Ring Groups – Departmental ring groups?
- Ring strategy, and remote call pickup?
- Destination on no answer
- IVR – Call trees, press 1 for sales, etc.
- What are all the options
- Destination on no selection
- Professional recording of message or user recorded
- Day/Night control
- Automatic or user controlled
- Individual DID
- Direct to extension calls available
- Call Queues for departments
- Ring Groups – Departmental ring groups?
- Outbound Call Flow
- Outbound CID
- Routing per trunk
- General Call Handling
- Paging
- Intercom
- Music on Hold
- Conferencing
- Call Parking – Putting calls on hold on “Line 1”
- Voicemail
- VM to Email
- Endpoint Management – How to manage desk phones
- What buttons need to be where on the screen of each phone.
Part of the FreePBX 13 Setup Guide
-
The first thing you need to do before you can begin a PBX project is to determine how many Direct Inward Dial (DID) numbers are involved.
The second thing you need to know is that a DID is not a line. The concept of a line is a legacy concept from the days of POTS service when each phone call took a dedicated copper pair. Phone service has not be restricted to the concept of a line since the first multiplexed service came out. The most well known thing would be the voice T1 that delivered 23 voice channels on a single copper pair.
So take the list of DID that you just gathered and figure out what they are all used for.
Generally you will only ever need 2 or 3 DID for any site, though only 1 is ever required.
Unless there is desire for everyone to have their own DID, this is the typical layout:
- DID 1: Main company number
- DID 2: Direct to IVR number
- Provide method of direct connection to all extensions
- Not needed if DID 1 goes direct to IVR and not a live person
- DID 3: Inbound Toll-Free number
- Not many businesses really need this anymore in the U.S. as the concept of paying special rates for long distance has generally faded thanks to ubiquitous all inclusive mobile calling.
Once you know the number of DID needed, you then need to determine the amount of calls that would be expected to go in and out of the system at the same time. This will not include extension to extension calling, only calling that have to go in or out the trunk to the outside world.
These are called concurrent calls, or some times call paths, and you need to know this number in order to purchase the right solution. If you consistently have 15 people on the phone with outside parties, then you need at least 15 concurrent calls available, and would more likely want to plan for 20.
Many SIP trunk providers have an offering for unlimited concurrent calls. Some will offer unlimited but put in a soft cap for fraud reduction. Basically it is easier to restrict the maximum number of calls than have to lose money dealing with subscribers who programmed a weak password someplace and a hacker used the PBX to route expensive calls. VoIP.ms does this and will move the cap to whatever you need. I believe theirs is set to 10 or 25 out the gate.
Once you know the number of DID and number of call paths you need, you will be able to look at service provider offerings with solid information on your actual needs and begin to sort through the available options.
-
The next point is inbound call flow. Before you can receive calls, in to your new system, you will have to tell it what to do with an inbound call. This is called inbound routing for obvious reasons.
Typically inbound routing boils down to one thing.- Is a real person gong to answer the phone, or is it going to an Interactive Voice Response (IVR) system?
There are of course more details needed, but this is the basic one.
The next question is, will you use an IVR? The answer here should always be, yes. Even if you will have a dedicated receptions answering the phone live all day long, you will need some kind of after hours handling. Additionally you should always provide a method for people to get around a receptions and directly to the person they wish to speak with.
Frequent callers get tired of always having to call in, ask for Bob in sales, and wait to get transferred or told he is on a call and asked ,"do you want his voicemail?" Instead, have an IVR ready on a secondary number if you have normal calls going in to a live person. This way, Bob in sales can have 314-555-1213 ext 262 on his business card and people can get through to him directly, instead of calling the main office number at 314-555-1212.
Finally, you need to know what to do with the calls after hours. Are you going to send them to an IVR, some after hours answering service, or a voicemail box? For a business, in today's world, I recommend that people simply use an IVR to let people dial through to an extension if they know it, while the IVR message should tell them to visit the website for contact via email or some such. The normal business has no need for anything more.
- Is a real person gong to answer the phone, or is it going to an Interactive Voice Response (IVR) system?
-
Third, you need to look at how you are handling outbound calls.
If you are coming from an older PBX or POTS lines, then there is not likely much you were doing except letting calls go out. With a modern PBX, you have a lot of choice on how to handle your calls.
Anything from a basic all calls go out, to some least cost routing, to restricting calls from certain extensions to certain destinations or only at certain times.
At a basic level you will have a single trunk and simply route all your calls out that trunk. Adding in extra trunks simply means adding in rules to the routing. This is done with dial pattern matching and listing the trunks in the order you want them used in the route.
Additionally, if you are using a SIP trunk, you can specify your outbound Caller ID (CID) as desired. By law you have to report only a telephone number you control, though it does not have to be one from the current service you are using, just one you control. This is a handy thing if you have multiple offices using a single PBX. You can setup the CID to based on the person calling to show the local number for that office. Even if you only have a single SIP trunk.
-
Finally, you need to look at the general way calls are handled in your organization.
This list contain many if not most of the things you should know prior to to picking a phone system.
How your company uses these features currently, as well as how well you design the new system going forward, can be a huge driver for acceptance or problems.
- Paging
- Intercom
- Music on Hold
- Conferencing
- Call Parking – Putting calls on hold on “Line 1”
- Voicemail
- VM to Email
- What buttons need to be where on the screen of each phone.
All of these features are fairly self explanatory, so I will not detail each of them. I will just say that you need to understand how these features currently work and how your new PBX implements them.
The one point I do want to highlight is endpoint management.
- Endpoint Management – How to manage desk phones
This one is going to be one that seriously hampers your day if you have any kind of scale at all. You most definitely want to have some centralized form of endpoint management setup.
By default FreePBX has a TFTP server enabled. If you are on a LAN, this makes things simply. If you are not it gets more complicated, but only for initial setup.
Almost every brand of phone takes config files. These are typically plain text files with a bunch of configuration information including the extension login credentials and the button configuration.
The Yealink phones that I like use two files. One based on the model of the phone and one based on the MAC. Setting these files up means getting a replacement phone is as simple as renaming a MAC file and booting up the new phone.
On top of doing this manually, FreePBX has a commercial module that you can purchase to allow you to configure things int he FreePBX GUI. This module is well worth the additional cost if your PBX is on the LAN. Because, not only can it create all the files for you, it does discovery and can push the config to the phone and force an update.
Whichever way you go, you need to look at setting up something. Nothing sucks quite as much as having to manually log into 60 phones to change a BLF on each phone because someone has had a name change.
-
Considerations for physical versus virtual?
-
@NerdyDad said in Things to know before you start installing FreePBX:
Considerations for physical versus virtual?
Yes, are you installing a PBX? Then virtual. It's a server like any other. If you need special hardware, consider doing it externally to the server or a passthrough to the VM. There is a possibility that you will have unique hardware that cannot handle virtualization - but you should consider not having that hardware if it forces you to violate decent good practices. Typically PBXs and phones are of some importance, so you want to treat the as such and that means virtual.
-
@scottalanmiller said in Things to know before you start installing FreePBX:
@NerdyDad said in Things to know before you start installing FreePBX:
Considerations for physical versus virtual?
Yes, are you installing a PBX? Then virtual. It's a server like any other. If you need special hardware, consider doing it externally to the server or a passthrough to the VM. There is a possibility that you will have unique hardware that cannot handle virtualization - but you should consider not having that hardware if it forces you to violate decent good practices. Typically PBXs and phones are of some importance, so you want to treat the as such and that means virtual.
This is funny - While I do agree, what Scott says makes total sense, but how many SMBs have you known (I'm not asking Scott) that have ever had a redundant phone system? Also, pre server based PBX, they were hardware setups that were fairly robust. Of course now moving them to little more than a software platform that runs on commodity hardware, we need to consider the reliability of that hardware compared to our need for uptime and decide where we draw the line. With that said being that this is just software running on a commodity hardware, we shouldn't treat this any different than we do a Windows or Linux based server. Virtualize unless there is a specific thing preventing us from doing so.
-
still need to type up point 4... but have to take the kids out.
-
@Dashrender said in Things to know before you start installing FreePBX:
This is funny - While I do agree, what Scott says makes total sense, but how many SMBs have you known (I'm not asking Scott) that have ever had a redundant phone system?
More importantly.... what difference does it make that you rarely see SMBs doing it? We aren't asking what SMBs who are failing to do IT well are doing, we are asking what we should do. And intentionally do something poorly because it is common to do it poorly is not good logic. Physical PBXs are both more expensive and more fragile. No upsides. SMBs have been easily mislead in the past, don't be those SMBs.
-
@Dashrender said in Things to know before you start installing FreePBX:
Also, pre server based PBX, they were hardware setups that were fairly robust.
"Fairly robust" is a relative term. The baseline of robustness is vastly higher today, those old PBXs are not robust in today's terminology. They were comparable to other technology of their day. They are laughably unexceptionable today. And their cost was always ridiculous.
Lots of things were done in the past that were acceptable then because there were not better options that should never be remotely considered today.
-
@Dashrender said in Things to know before you start installing FreePBX:
Of course now moving them to little more than a software platform that runs on commodity hardware...
That's all that they normally ever were. Just it wasn't exposed for you to put it on quality commodity hardware or have failover or recovery options.
-
@scottalanmiller said in Things to know before you start installing FreePBX:
@Dashrender said in Things to know before you start installing FreePBX:
Of course now moving them to little more than a software platform that runs on commodity hardware...
That's all that they normally ever were. Just it wasn't exposed for you to put it on quality commodity hardware or have failover or recovery options.
This is why I did not even make a point for virtual or not. It will be virtual or you did something wrong.
-
ok finally posted details for point 4.
-
Would love to see how you provision phones using FreePBX without endpoint manager. Been searching the Wiki but all I have found involves their EPM.
-
@bigbear said in Things to know before you start installing FreePBX:
Would love to see how you provision phones using FreePBX without endpoint manager. Been searching the Wiki but all I have found involves their EPM.
that is on my to do here, but I posted this process within the last week for someone on this forum. let me try and find the thread.
-
@bigbear I gave an example config in this thread specifically because you asked.
-
Yeah that guy was an ass... lol
What folder on the server do you place the config files in for https?
-
+1 on everything @JaredBusch . Not needed now but valuable for future!
@Dashrender ans @scottalanmiller currently we use one of these -
@bigbear said in Things to know before you start installing FreePBX:
Yeah that guy was an ass... lol
What folder on the server do you place the config files in for https?
it all goes in the /tftpboot folder. FreePBX handles that in the apache vhost config. port 1443 goes there.
