Make quick apps for your small local team, but large international teams beware of the limitations!
Overall Satisfaction with Quick Base
We use QuickBase to accept requests from one team to another, store information about those requests, automatically generate due dates/times based on task type, and track status and who is assigned to each request. We also return results within QuickBase and send emailed notifications when the results are ready. We log time estimates, hours spent, and have formulas set up to track SLA Compliance for each task type. We get a lot of data about all parts of our operations from the QuickBase reports. We have many teams using QuickBase in this manner, each with a workflow customized to their specific needs.
We also have some other QuickBases set up to manage our internal training program and a similar one for client training, an internally facing client feedback tracker, management statistics for our support team, a lightweight bug tracker, and some smaller solutions here and there.
- QuickBase allows a business user to customize or build an app with minimal database skills. If you can use MS Access, you can build a full-featured cloud-based app with QuickBase.
- QuickBase is easy to customize one the app is live. There is very low risk to deploying updates to the live environment because most updates are fast to make and just as fast to roll back if needed.
- QuickBase customer support is excellent. They respond quickly and tend to have a very good understanding of the product. Support team is always willing to get on the phone with me and help solve my QuickBase puzzle.
- QuickBase is bad at supporting international business. There is no native support for user-based time zones or date formats. The database uses a character encoding that won't support languages besides English. The support team and staff are obviously not used to thinking about international business and seem stumped when asked how to solve for these problems.
- QuickBase's user interface is humdrum. It's possible to design a form for your users that is usable, but it does not look modern and elegant.
- QuickBase's mobile support is poor. It is possible to view your quickbase on a phone or tablet, but it's difficult to navigate most apps and takes many clicks/taps.
- QuickBase's per-user pricing makes it a bad choice for client-facing applications. You would have to pay for your internal users and for each client user.
- QuickBase is very receptive to feedback on their limitations, however their sales and support staff will constantly push you to solve for limitations on UI, mobile support, or client-facing applications by using a third party vendor who builds their app on top of QuickBase and will charge additional money to do so. The overall value proposition goes down when you take this into consideration.
- QuickBase charges per user, but does not provide any easy tools for user audits or user management. Any app builder in my company can invite any number of new users and they will be added to my bill without any option for me to block them.
- It is not easy to do inline editing of a table report in QuickBase. Their grid edit solution is very buggy and users often lose their changes to the data when encountering a bug in grid edit.
- Sales Force
New users can certainly create apps, but may take a little longer to get up to speed and get their app deployed. I especially notice a lot of new users get confused with the concept of table-to-table relationships. Typically someone who has never worked with a database will need to learn the very basics of database structure and design before they can really leverage the power of QuickBase. Thankfully QuickBase offers several recorded webinars that explain the basics from a QuickBase perspective quite well.
I notice our newer QuickBase admins tend to make some structural mistakes in building their apps---doing things the hard way sometimes. These mistakes can be difficult to undo once the app is being used by many users. However, QuickBase offers community forums, recorded webinars, a fantastic and complete help center, and a support team. If a new developer takes advantage of all that QB has to offer, they can avoid such mistakes and come up with a really nice basic app to which they can add features over time.
- Building and deploying business applications faster
- Improving our ability to drive insights from our data
- Improving collaboration across one or more teams
Simple updates like adding a field, adding a look-up field, changing a dropdown, customizing an email notification--these are completed in a minute or two and immediately available to users. This is an advantage of QuickBase over any other product I have tried.
There are more complex scenarios wherein one discovers that the base structure of an app is not ideal. Recently we had to entirely rebuild a major app from which we gain data about all our clients. It was time-consuming because we decided to do it right, but the results have been well worth it. We started by creating a data dictionary for the old app. There is no easy way to export a data dictionary from QuickBase so this was more time-consuming than it should be. I had to copy/paste from an admin screen then remove the garbage data. We then re-mapped the tables of the app into a more logical structure and decided which fields to keep/change/remove. We logged all that in our spreadsheet before beginning any app building. Finally, with the new data mapping in mind, we exported all the old data from the old app and adjusted the spreadsheets so that it would be in the correct structure (and field names) for the new app. We then built the new app and imported the data. The total process took maybe 2-3 months, but the end result is an app that is very easy to use and update moving forward. I don't expect to ever need to make major structural changes to this app because it was built with flexibility in mind.
So there you have it---the most complex rebuild of a complex app took 3 months at max. Keep in mind this was a side project for us, as we have zero people dedicated full time to supporting QuickBase. The operations owners take care of it in their spare time.
QuickBase is not good at storing huge quantities of data. It's good for simple data analysis, but not for anything more complex or detailed. You will always have to export your data to Excel if you want to fully customize the reports and graphs, for example to add them to a presentation for upper management. We have a time-tracking table with over 1million records over the course of the last 2.5 years and it has become very slow and difficult to report on. Unfortunately now that we have so many records, archiving the data is also very difficult. The table is connected to a dozen or more other tables, across multiple apps. On the plus side, this provides great flexibility allowing us to report on time spent per project in a central location. On the minus side, QB just can't handle this quantity of data without errors. I suggest exporting data regularly and doing large analysis in Excel or somewhere else outside of QuickBase. Come up with an archive strategy early on so that you aren't stuck.
Using Quick Base
- Employee time tracking, relating hours data to revenue to assess profitability
- Project management and visibility for various longer term projects
- Request management for various shorter term requests, including tracking SLA adherence
- We need better national and international support. Users need to be able to set their own personal time zone and then view all times or date/times within an app in their home time zone. They also need to be able to enter the times in their home time zone and it automatically gets translated back to the app's time zone upon save. While there is a workaround for viewing timestamps, there is no workaround for creating or updating timestamps outside of working with a QSP.
- We need users to be able to create a QB record by emailing a special email address. Gmail sync doesn't quite do the trick. If we had this feature, we could support ticketing workflows.
- We'd like to get more granular in our ability to track metrics related to requests. For example, if we need to track the time spent on hold for a request that goes in and out of hold status several times, it is difficult to do right now. We are close to a workaround with the new Automations feature, but Automations don't allow date fields to be used as report criterion for triggers.
We are able to justify the extra cost of Quick Base because it saves us from buying other point solutions for individual problems.