How-To: Building a Coworking System
When we opened the first Hub space in 2011 with 70 members, we created our system from scratch based on necessity. The first tool that we added was Google Apps - as with many small businesses, our backbone was based off Google. Next came tools for billing members and accepting applications. We added tools as we needed them with minimal research, but there wasn’t much thought put into an overall system as we moved quickly and didn’t exactly know what we needed. Our biggest decision-making factors for taking on a new tool were cost and an open API. About six months into operations, with multiple tools making up our systems and more experience knowing our operational needs, we took a step back and invested time into major research for a system that would cover all of our bases. At this point, we needed billing, a CRM, and event booking capabilities integrated - we had cobbled together several different tools that had open APIs, but were quickly realizing the inefficiency created with this method.
Our then-current system and needs were captured in several write-ups, and RFPs were created to send out to different contractors; ultimately, this process told us that there wasn’t really a silver bullet out there that covered all of our needs. So, we continued on with our current system.
As we moved into our new, 40,000sf space in October of 2012, our systems moved with us. The biggest changes we have made to our systems over the last four years have been:
Collecting customer data. We’ve collected different types of customer data throughout our history of operations. Some of the hardest parts about collecting customer data are:
You should only collect data that you can use...
BUT, when you’re working with communities, you may want to collect data that you think may be of use in the future that you’re not using at the moment, so you feel like you have to collect all of the data you may want in the future, all at the same time.
We ended up with a very messy CRM and imperfect data because we collected different types of data at different times.
Network. Our network was the primary focus as we moved into a larger space. We initially bootstrapped the network build-out, which meant that we worked with our provider (we initially contracted with a local provider of microwave internet, at 100mbps bandwidth) to build out the network infrastructure ourselves to save money. While I will spare you the dirty details, in the long-run this was a mistake - we ended up going through several major network upgrades over the last four years. The major six parts of our upgrades were:
Switching to fiber and running our own cables throughout the building (through a professional contractor);
Replacing all of our APs to smart Cisco Meraki APs (through a managed contract with our fiber provider, Century Link);
Rebuilding the AP distribution throughout the building;
Bringing all of our equipment in-house (this included routers and firewalls, which were owned and operated by our initial internet provider, which meant we didn’t have full access and control over the equipment and its configurations until we owned it ourselves);
Implementing a back-up network in case of primary network failure;
Network access control (the final system upgrade described below will ultimately support this with user login IDs, instead of one shared network with one password).
Billing and accounting. We moved from doing accounting in-house to outsourcing with an accounting firm, which was a major mark in our growth. In order to do so, we needed to bring on other tools that our accounting firm used, such as Quickbooks. Quickbooks doesn’t currently integrate with the large majority of our tools, so in exchange for a new service to the company, we had to add on more manual processes and reports for our billing manager to update to ensure that all tools were updated correctly.
Other than these three changes, our system has remained largely the same as it was when we first started, even as we grew from 70 to over 700 members. We have severely outgrown these systems, most obvious through our billing process. Our billing manager spends over 60% of her time on member churn - new members joining, member cancellations, and members changing levels. Because our billing system is completely manual, the process for member churn is manual; that means that a member needs to email our billing manager to request a change or cancellation. Obviously, with the growth that we’ve seen, that level of churn is more and more difficult and time-consuming to do manually.
Another inefficiency of our current system is the way that we book events; right now, anyone can book an event through our website using the same system that we had when we only had 1 space to book - now we have 10. Booking and invoicing continues to be a manual process, meaning that our event manager spends the majority of her time on fulfilling quotes and manually entering information, instead of spending valuable time on follow-up and customer service.
Lastly, our current tracking system for member usage is based on an honor system. All tracking is done manually, meaning that people have to sign-in in order to use one of their ‘days’, and even if members do want to honorably track their days (most do!), they cannot check how many days they’ve used and how many days left they have on their plan.
Basically — we make it incredibly difficult for our customers to pay us.
Based on our growth, the amount of time that our team spends on member communication and manual processes for billing and event booking-related activities, we decided to invest in an overall system upgrade, with the goal to move to one platform that would encapsulate automatic booking and automatic member usage tracking; this platform would have an open API so we could add on additional tools that covered all of our needs. However, automatic billing plans and member usage tracking were the two most important parts of an overall system upgrade, both from a time-saving and revenue-generating perspective.
There were three key pieces to the overall system upgrade process:
1) Discovery. We invested a huge amount of time in discovery, meaning that we needed to completely understand the problem before developing an RFP for what was necessary. We hired a contractor for the entire process (someone that had been working with Impact Hub prior, which was helpful) - this person spent an hour and a half with each team member going through their day-to-day, pain points, and process. The output from this process was a compilation of criteria that platform research would be judged against, as well as the initial draft of an RFP for all of the components necessary for an overall system upgrade. This process took about 30 hours in total.
2) Research. From the Discovery phase, we had developed a set of criteria to gauge platform research. Our contractor then spent about 5+ hours developing a design for showcasing this criteria, and did some initial research to identify a number of platforms that would be researched further and judged based on our criteria. We came up with 20 different platforms to be researched in all. Our contractor spent about 5 hours per platform at first, diving in to ensure that each platform met our needs. He spent over 20 hours on the platforms that showed the most promise in solving our core needs, primarily working with the platform developer team to identify and address concerns, and actually importing our own data and running tests within the platform.
The Research process culminated with a presentation based on the research that had been done, and the contractor’s overall recommendation on moving forward with a platform. Expectations were set with the team prior to that meeting that they had a venue to provide feedback and ask questions, but that we would move forward with one platform after that presentation.
3) Implementation planning and timeline. Since a system upgrade touched every single team member, we needed one team member to lead the implementation process from the team perspective, which meant: developing a timeline for a staged implementation (since not all components would be implemented at once) and most importantly, identifying the amount of time each team member would need to spend on making the system transfer (based on their area of the business) and for training how to use the new system components. Our billing manager became the project lead for this upgrade.
A huge part of this system upgrade was carving out time for our billing manager to work alongside our contractor and think strategically about what implementation looked like for everyone. She was at capacity in terms of workload before taking on project lead, so we brought on an on-site assistant to help take some of the manual billing tasks off her plate.
All in all, our overall system upgrade will include the following components in a staged roll-out. The components in bold are the components that must be fully encapsulated in the chosen platform from the Research phase:
Customizable billing plans
Member intranet & help desk
Member usage tracking & security
Event booking capabilities
The other components will be chosen based on the known problems from the Discovery phase, and added on a staged timeline based on their compatibility with the initial platform.
Ultimately, developing a system that supported all of our needs was non-existent, so the first thing that we needed to keep in mind as a team was that there was no perfect solution. However, we feel confident that our approach to an overall systems upgrade will pay off because of our initial investment in a discovery process.