When you’re looking to roll out your first beacon project, and you're wondering how it could look like, there are hundreds of beacon use cases to help you get inspired. But when you’re planning to deploy, success stories aren’t a sufficient guidance anymore. You need go-to tips based on real-world experiences. You need to learn from people who successfully beaconized many venues so that you can follow their steps instead of starting from scratch.
So meet Indoo.rs, BeaconsTalk, Linteri, and Zii.io, companies deploying beacons and developing proximity-enabled software on a daily basis. They kindly agreed to share their secret tips and tricks to help make your beacon proof of concept a victory. Here’s what they recommend.
(If you want to dive deeper and get step-by-step instructions on how to plan, handle, and test a first beacon deployment, be sure to download our free Guide to Beacon POCs!)
There are three main things that we have learnt over many POCs. Good communication is of utmost importance.
This means the following:
The second and equally important is work with people who know what they are doing or are willing to learn. So have well-defined instructions, easy to follow guides, and train your staff well.
The third is, focus on a representative area. Remember the POC should show that your success in the limited area can be reproduced for the full area/scope.
When you’re dealing with proximity and mobile technologies, there are so many tasks to be done, that it’s impossible for one person to handle them all. You need to setup a solid team.
Looking at beacon-based projects that we at Linteri have worked on, I think that a perfect beacon POC team should consist of:
It all depends on your project whether all the people listed above are necessary. For example, you may decide to mount beacons by yourself (in this case, make sure to contact the building administration and receive consent beforehand.)
Always have a Project Manager, as this person needs to juggle between different areas of the POC and make sure all the people are available and have all the information they need. At early stages, a Project Manager can also replace a business analyst and help you verify if the POC meets the customer’s needs.
Since you’ll often need to change beacon parameters to check the signal propagation, you’ll also need a technical person who knows how to reconfigure the beacons on the go.
All the technologies aside, make sure to bring the good ol’ pen and paper and floor plan printouts—they’ll make the job of all your team members easier!
Organizing a beacon fleet is essential to the success of any Proof of Concept. It gives a solid base for expansion if the POC takes off. It gives you the benefit of knowing which beacons will cover which locations and an organized way of replacing beacons if necessary. And it will come in handy when performing any QA procedures or tests on site. The best way to start is to create a foundation for your POC beacon fleet.
To do this, you must first decide how you will place your beacons onsite.
Create a map of the beacon placements, and annotate each location with the corresponding ID tag. When choosing the best placements for your beacons, make sure to equally distribute the coverage across all areas listed in the POC. Keep in mind that the effective range of a beacon is about 100ft, and that will change when placing the beacon indoors. You can also label each beacon with a special identifier that is separate from the ID tag. I found the easiest way is to split the beacons by floor, and then organize them in ascending order. “1st,B1” would signify that this is the 1st beacon on the 1st floor- simple. This labeling can be as complex as it needs to be, but the main goal is to keep track of which beacons went where. Once all the labeling is done, make sure to take pictures of the beacon tags with the labels written on; this will ensure that you know exactly which beacon belongs to which label. Also make sure to separate the beacons into different containers labeled with the floor number.
A strong and well-kept beacon fleet is invaluable to you, and your POC. Any time that would have been spent dealing with beacon management can now be allotted towards perfecting your POC.
Testing and bug fixing are crucial to making your POC a success, so you need to make sure you go through this stage without pitfalls. There are some general rules you need to follow but remember that everything depends on your context: a use case, venue, and even the country you operate in.
For example in India, where BeaconsTalk mostly deploys, we must take into account that places we beaconize will be ultimately far more crowded that during POCs. It also happens here that beacons get stolen or damaged; so in deployments where accuracy is critical, we have to test if an infrastructure can effectively keep running without some units.
Considering BeaconsTalk’s experiences, here’s what I recommend doing while testing your beacon fleet:Set up a testing environment in a small part of a venue and make sure it isn’t too busy during operation hours
How will these tips help your beacon deployments? Is there any particular takeaway you'll use in your next deployments? Maybe there is another approach that's worked for you? Hit the comments below and share your thoughts!