Three months, 30x demand: How we scaled Google Meet during COVID-19
4175
Of your peers have already read this article.
10:30 Minutes
The most insightful time you'll spend today!
As COVID-19 turned our world into a more physically distant one, many people began looking to online video conferencing to maintain social, educational, and workplace contact. As shown in the graph below, this shift has driven huge numbers of additional users to Google Meet.
In this post, we’ll share how we ensured that Meet’s available service capacity was ahead of its 30x COVID-19 usage growth, and how we made that growth technically and operationally sustainable by leveraging a number of site reliability engineering (SRE) best practices.
Early alerts
As the world became more aware of COVID-19, people began to adapt their daily rhythms. The virus’s growing impact on how people were working, learning, and socializing with friends and family translated to a lot more people looking to services like Google Meet to keep in touch. On Feb. 17, the Meet SRE team started receiving pages for regional capacity issues.
The pages were symptomatic, or black-box alerts, like “Too Many Task Failures” and “Too Much Load Being Shed.” Because Google’s user-facing services are built with redundancy, these alerts didn’t indicate ongoing user-visible issues. But it soon became clear that usage of the product in Asia was trending sharply upward.
The SRE team began working with the capacity planning team to find additional resources to handle this increase, but it became obvious that we needed to start planning farther ahead, for the eventuality that the epidemic would spread beyond the region.
Sure enough, Italy began its COVID-19 lockdown soon thereafter, and usage of Meet in Italy began picking up.
A non-traditional incident
At this point, we began formulating our response. True to form, the SRE team began by declaring an incident and kicking off our incident response to this global capacity risk.
It’s worth noting, however, that while we approached this challenge using our tried-and-true incident management framework, at that point we were not in the middle of, or imminently about to have, an outage. There was no ongoing user impact. Most of the social effects of COVID-19 were unknown or very difficult to predict. Our mission was abstract: we needed to prevent any outages for what had become a critical product for large amounts of new users, while scaling the system without knowledge of where the growth would come from and when it would level off.
On top of that, the entire team (along with the rest of Google) was in the process of transitioning into an indefinite period of working from home due to COVID-19. Even though most of our workflows and tools were already accessible from beyond our offices, there were additional challenges associated with running such a long-standing incident virtually.
Without the ability to sit in the same room as everyone else, it became important to manage communication channels proactively to ensure we all had access to the information needed to achieve our goals. Many of us also had additional, non-work related challenges, like looking after friends and family members as we all adjusted. While these factors created extra challenges for our response, tactics like assigning and ramping up standbys and proactively managing ownership and communication channels helped us overcome these challenges.
Nevertheless, we carried on with our incident management approach. We started our global response by establishing an Incident Commander, Communications Lead, and Operations Lead in both North America and Europe so that we had around-the-clock coverage.
As one of the overall Incident Commanders, my function was like that of a stateful information router—albeit with opinions, influence, and decision-making power. I collected status information about which tactical problems lingered, who was working on what, and on the contexts that affected our response (e.g. governments’ COVID-19 responses), and then dispatched work to people who were able to help. By sniffing out and digging into areas of uncertainty (both in problem definition: “Is it a problem that we’re running at 50% CPU utilization in South America?” and solution spaces: “How will we speed up our turn-up process?”), I coordinated our overall response effort and ensured that all necessary tasks had clear owners.
Not long into the response, we realized that the scope of our mission was huge and the nature of our response would be long-running. To keep each contributor’s scope manageable, we shaped our response into a number of semi-independent workstreams. In cases where their scopes overlapped, the interface between the workstreams was well-defined.
We set up the following workstreams, visible in the diagram above:
- Capacity, which was tasked with finding resources and determining how much of the service we could turn up in which places.
- Dependencies, which worked with the teams that own Meet’s infrastructure (e.g., Google’s account authentication and authorization systems) to ensure that these systems also had enough resources to scale with the usage growth.
- Bottlenecks, which was responsible for identifying and removing relevant scaling limits in our system.
- Control knobs, which built new generic mitigations into the system in the case of an imminent or in-progress capacity outage.
- Production changes, which safely brought up all of the found capacity, re-deployed servers with newly-optimized tuning, and pushed new releases with additional control knobs ready to be used.
As incident responders, we continuously re-evaluated if our current operational structure still made sense. The goal was to have as much structure as required to operate effectively, but no more. With too little structure, people make decisions without having the right information, but with too much structure, people spend all of their time in planning meetings.
This was a marathon, and not a sprint. Throughout, we regularly checked in to see if anyone needed more help, or needed to take a break. This was essential in preventing burnout during such a long incident.
To help prevent exhaustion, each person in an incident response role designated another as their “standby.” A standby attended the same meetings as the role’s primary responder; got access to all relevant documents, mailing lists, and chat rooms; and asked the questions they’d need answers to if they had to take over for the primary without much notice. This approach came in handy when any of our responders got sick or needed a break because their standby already had the information they needed to be effective right away.
Building out our capacity runway
While the incident response team was figuring out how best to coordinate the flow of information and work needed to resolve this incident, most of those involved were actually addressing the risk in production.
Our primary technical requirement was simply to keep the amount of regionally available Meet service capacity ahead of user demand. With Google’s more than 20 data centers operating around the world, we had robust infrastructure to tap into. We quickly made use of raw resources already available to us, which was enough to approximately double Meet’s available serving capacity.
Previously, we relied on historical trends to establish how much more capacity we’d need to provision. But because we could no longer rely on the extrapolation of historical data, we needed to begin provisioning capacity based on predictive forecasts. To translate those models into terms our production changes team could act upon in production, the capacity workstream needed to translate the usage model into how much additional CPU and RAM we needed. Building this translation model is what later enabled us to speed up the process of getting available capacity in production, by teaching our tools and automation to understand it.
Soon, it became clear that merely doubling our footprint size was not going to be enough, so we started working against a previously unthinkable 50x growth forecast.
Reducing resource needs
In addition to scaling up our capacity, we also worked on identifying and removing inefficiencies in our serving stack. We could bucket much of this work into a couple of categories: tuning binary flags and resource allocations and rewriting code to make it cheaper to execute.
Making our server instances more resource-efficient was a multi-dimensional effort—the goal could be phrased as “the most requests handled at the cheapest resource cost, without sacrificing user experience or reliability of the system.”
Some investigative questions we asked ourselves included:
- Could we run fewer servers with larger resource reservations to reduce computational overhead?
- Had we been reserving more RAM than we needed, or more CPU than we needed? Could we better use those resources for something else?
- Did we have enough egress bandwidth at the edge of our network to serve video streams in all regions?
- Could we reduce the amount of memory and CPU needed by a given server instance by subsetting the number of backend servers in use?
Even though we always qualified new server shapes and configurations, at this point, it was very much worth reevaluating them. As Meet usage grew, its usage characteristics—like how long a meeting lasts, the number of meeting participants, how participants share audio time—also shifted.
As the Meet service required ever more raw resources, we began noticing that a significant percentage of our CPU cycles were being spent on process overhead like keeping connections to monitoring systems and load balancers alive, rather than on request handling.
In order to increase the throughput, or “number of requests processed per CPU per second,” we increased our processes’ resource specification in terms of both CPU and RAM reservation. This is sometimes called running “fatter” tasks.
In the example data above, you will notice two things: that all three of the instance specifications have the same computational overhead (in red), and that the larger the overall CPU reservation of an instance, the more request throughput it has (in yellow). With the same total amount of CPU allocated, one instance of the 4x shape can handle 1.8 times as many requests as the four instances with the baseline shape. This is because the computational overhead (like persisting debug log entries, checking if network connection channels are still alive, and initializing classes) doesn’t scale linearly with the number of incoming requests the task is handling.
We kept trying to double our serving tasks’ reservations while cutting in half the number of tasks across our fleet until we hit a scaling limitation.
Of course, we needed to test and qualify each of these changes. We used canary environments to make sure that these changes behaved as expected and didn’t introduce or hit any previously undiscovered limitations. Similar to how we qualify new builds of our servers, we qualified that there weren’t any functional or performance regressions, and that the desired effects of the changes were indeed realized in production.
We also made functional improvements to our codebase. For example, we rewrote an in-memory distributed cache to be more flexible in how it sharded entries across task instances. This, in turn, let us store more entries in a single region when we grew the number of server instances in a cluster.
Crafting fire escapes
Though our confidence in our usage growth forecasts was improving, these predictions were still not 100% reliable. What would happen if we ran out of serving capacity in a region? What would happen if we saturated a particular network link? The control knob workstream’s goal was to provide satisfactory, if not ideal, answers to those kinds of questions. We needed an acceptable plan for any black swans that arrived on our consoles.
A group began working to identify and build more production controls and fire escapes—all of which we hoped we wouldn’t need. For example, these knobs would allow us to quickly downgrade the default video resolution from high-definition to standard-definition when someone joined a Meet conference. That change would buy us some time to course-correct using the other workstreams (provisioning and efficiency improvements) without substantial product degradation, but users would still be able to upgrade their video quality to high-definition if they wanted to.
Having a variety of instrumented controls like this built, tested, and ready to go bought us some additional runway if our worst-case forecasts weren’t accurate—along with some peace of mind.
Operational sustainability
This structured response involved large numbers of Googlers in a variety of roles. This meant that to keep making progress throughout the incident, we also needed some serious coordination and intentional communications.
We held daily handover meetings between our two time zones to accommodate Googlers based in Zurich, Stockholm, Kirkland, Wash., and Sunnyvale, Calif. Our communications leads provided regular updates to numerous stakeholders across our product team, executives, infrastructure teams, and customer support operations so that each team had up-to-date status information when they made their own decisions. The workstream leads used Google Docs to keep shared status documents updated with current sets of risks, points of contact, ongoing mitigation efforts, and meeting notes.
This approach worked well enough to get things going, but soon began to feel burdensome. We needed to lengthen our planning cycle from days to weeks in order to meaningfully reduce the amount of time spent coordinating, and increase the time we spent actually mitigating our crisis.
Our first tactic here was to build better and more trustworthy forecasting models. This increased predictability meant we could stabilize our target increase in serving capacity for the whole week, rather than just for tomorrow.
We also worked to reduce the amount of toil necessary to bring up any additional serving capacity. Our processes, just like the systems we operate, needed to be automated.
At that point, scaling Meet’s serving stack was our most work-intensive ongoing operation, due to the number of people who needed to be up-to-date on the latest forecast and resource numbers, and the number of (sometimes flaky) tools involved in certain operations.
As outlined in the life-cycle diagram above, the trick to automating these tasks was incremental improvements. First we documented tasks, and then we began automating pieces of them until finally, in the ideal case, the software could complete the task from start to finish without manual intervention.
To accomplish this, we committed a number of automation experts from within and outside the Meet organization to focus on tackling this problem space. Some of the work items here included:
- Making more of our production services responsive to changes in an authoritative, checked-in configuration file
- Augmenting common tools to support some of Meet’s more unique system requirements (e.g., its higher bandwidth and lower latency networking requirements)
- Tuning regression checks that had become more flaky as the system grew in scale
Automating and codifying these tasks made a significant dent in the manual operations required to turn up Meet in a new cluster or to deploy a new binary version that would unlock performance improvements. By the end of this scaling incident, we were able to fully automate our per-zone, per-serving job capacity footprint, which precluded hundreds of manually constructed invocations of command-line tools. This freed up time and energy for more than a few engineers to work on some of the more difficult (but equally important) problems.
At this point in scaling our operations, we could move to “offline” handoffs between sites via email, further reducing the number of meetings to attend. Now that our strategy was solidified and our runway was longer, we moved into a more purely tactical mode of execution.
Soon after, we wound down our incident structure and began to operate the remaining work more like how we’d run any long-term project.
Results
By the time we exited our incident, Meet had more than 100 million daily meeting participants. Getting there smoothly was not easy or straightforward; the scenarios the Meet team explored during disaster and incident response tests prior to COVID-19 did not encompass the length or the scale of increased capacity requirements we encountered. As a result, we formulated much of our response on the fly.
There were plenty of hiccups along the way, as we had to balance risk in a different way than we normally do during standard operations. For example, we deployed new server code to production with less canary baking time than normal because it contained some performance fixes that bought us additional time before we were due to run out of available regional capacity.
One of the most crucial skills we honed throughout this two month-long endeavour was the ability to catalog, quantify, and qualify risks and payoffs in a way that was flexible. Everyday, we learned new information about COVID-19 lockdowns, new customers’ plans to start using Meet, and available production capacity. Sometimes this new information made obsolete the work we’d started the day before.
Time was of the essence, so we couldn’t afford to treat each work item with the same priority or urgency, but we also couldn’t afford not to hedge our own forecast models. Waiting for perfect information wasn’t an option at any point, so the best we could do was build out our runway as much as possible, while making calculated but quick decisions with the data we did have.
All of this work was only possible because of the savvy, collaborative, and versatile people across a dozen teams and as many functions—SREs, developers, product managers, program managers, network engineers, and customer support—who worked together to make this happen.
We ended up well-positioned for what came next: making Meet available for free to everyone with a Google account. Normally, opening the product up to consumers would have been a dramatic scaling event all on its own, but after the intense scaling work we’d already done, we were ready for the next challenge.
Google’s Intelligent Products Essentials Assist Manufacturers in Product Development Journey
6953
Of your peers have already read this article.
3:00 Minutes
The most insightful time you'll spend today!
Expectations for both consumer and commercial products have changed. Consumers want products that evolve with their needs, adapt to their preferences, and stay up-to-date over time. Manufacturers, in turn, need to create products that provide engaging customer experiences not only to better compete in the marketplace, but also to provide new monetization opportunities.
However, embedding intelligence into new and existing products is challenging. Updating hardware is costly, and existing connected products do not have the capability to add new features. Furthermore, manufacturers do not have sufficient customer insights due to product telemetry and customer data silos, and may lack the AI expertise to quickly develop and deploy these features.
That’s why today we’re launching Intelligent Products Essentials, a solution that allows manufacturers to rapidly deliver products that adapt to their owners, update features over-the-air using AI at the edge, and provide customer insights using analytics in the cloud. The solution is designed to assist manufacturers in their product development journeys—whether developing a new product or enhancing existing ones.
With Intelligent Products Essentials, manufacturers can:
- Personalize customer experiences: Provide a compelling ownership experience that evolves over the lifetime of the product. For example, a chatbot that contextualizes responses based on product status and customer profile.
- Manage and update products over-the-air: Deploy updates to products in the field, gather performance insights and evolve capabilities over time with monetization opportunities.
- Predict parts and service issues: Detect operating thresholds, anomalies and predict failures to proactively recommend service using AI, reducing warranty claims, decreasing parts shortages and increasing customer satisfaction.
In order to help manufacturers quickly deploy these use cases and many more, Intelligent Products Essentials provides the following:
- Edge connections: Connect and ingest raw or time-series product telemetry from various device platforms utilizing IoT Core or Pub/Sub and enable deployment and management of firmware over-the-air and machine learning models with Vertex AI at the edge.
- Ownership App Template: Easily build connected product companion apps that work on smartphones, tablets, and computers. Use a pre-built API and accompanying sample app that can incorporate product or device registration, identity management, and provide application behavior analytics using Firebase.
- Product fleet management: Manage, update and analyze fleets of connected products via APIs, Google Kubernetes Engine, and Looker.
- AI services: Create new features or capabilities for your products using AI and machine learning products such as DialogFlow, Vision AI, AutoML, all from Vertex AI.
Enterprise data integration: Integrate data sources such as Enterprise Asset Management (EAM), Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) systems and others using Dataflow and BigQuery.
Intelligent Products Essentials helps manufacturers build new features across consumer, industrial, enterprise, and transportation products. Manufacturers can implement the solution in-house, or work with one of our certified solution integration partners like Quantifi and Softserve.
“The focus on intelligent products that Google Cloud is deploying provides a digital option for manufacturers and users. At its heart, systems like Intelligent Product Essentials are all about decision making. IDC sees faster and more effective decision-making as the fundamental reason for the drive to digitize products and processes. It’s how you can make faster and more effective decisions to meet heightened customer expectations, generate faster cash flow, and better revenue realization,” said Kevin Prouty, Group Vice President at IDC. “Digital offerings like Google’s Intelligent Product Essentials potentially go the last mile with the ability to connect the digital thread all the way through to the final user.”
Customers adopting Intelligent Products Essentials
GE Appliances, a Haier company, are enhancing their appliances using new AI-powered intelligent features to enable:
- Intelligent cooking: Help cook the perfect meal to personal preferences, regardless of your expertise and abilities in the kitchen.
- Frictionless service: Build smart appliances that know when they need maintenance and make it simple to take action or schedule services.
- Integrated digital lifestyle: Make appliances useful at every step of the way by integrating them with digital lifestyle services – for example, automating appliance behaviors according to customer calendars, such as oven preheating or scheduling the dishwasher to run in the late evening.
“Intelligent Products Essentials enhances our smart appliances ecosystem, offering richer consumer habit insights. This enables us to develop and offer new features and experiences to integrate with their digital lifestyle.“ —Shawn Stover, Vice-president Smart Home Solutions at GE Appliances.https://www.youtube.com/embed/zaWAJN8aKOw?enablejsapi=1&
Serial 1, Powered by Harley-Davidson, is using Intelligent Product Essentials to manage and update its next generation eBicycles, and personalize its customers’ digital ownership experiences.
“At Serial 1, we are dedicated to creating the easiest and most intuitive way to experience the fun, freedom, and adventure of riding a pedal-assist electric bicycle. Connectivity is a key component of delivering that mission, and working together to integrate Intelligent Product Essentials into our eBicycles will ensure that our customers enjoy the best possible user experience.”— Jason Huntsman, President, Serial 1.
Magic Leap, an augmented reality pioneer with industry-leading hardware and software, is building field service solutions with Intelligent Products Essentials with the goal of connecting manufacturers, dealers, and customers to more proactive and intelligent service.
“We look forward to using Intelligent Products Essentials to enable us to rapidly integrate manufacturers’ product data with dealer service partners into our field service solution. We’re excited to partner with Google Cloud as we continue to push the boundaries of physical interaction with the digital world.” — Walter Delph, Chief Business Officer, Magic Leap
Intelligent Product Essentials is available today. To learn more, visit our website.
Google Cloud’s Virtual Appointment Scheduling Tool (VAST) Helps State of Arizona Recover from Unemployment Situation
6556
Of your peers have already read this article.
2:00 Minutes
The most insightful time you'll spend today!
When the world was forced to go primarily online, state governments also faced the reality of needing to provide community services without the health risk of meeting in person. Old systems that relied on interpersonal contact could not keep up. An unprecedented number of displaced workers swamped every unemployment system. The capacity challenges weren’t limited to state labor departments either. Everything from birth certificates and marriage licenses to apostilles and court system services that could usually be handled by a simple walk-in had to be scheduled in advance. Both internal and external communication suffered.
To meet these challenges, many organizations turned to new technology solutions and innovative approaches.
How VAST helped Arizona get back to work
The State of Arizona had tens of thousands of constituents who relied on pandemic unemployment insurance and would also need tools to reenter the workforce.Tim Tucker, Deputy Administrator of the Workforce Development Administration for the Arizona Department of Economic Security, started preparing in late 2020. He collaborated with Google Cloud and SADA to introduce the Virtual Appointment Scheduling Tool (VAST) to State of Arizona staff members. Using VAST reduced the excessive workload taken on by the Workforce Development Administration as they got Arizona back to work. VAST lets constituents book an appointment, upload documents and forms, and conduct career counseling virtually. This helped constituents move through the system faster so they could successfully reenter the workforce.
That preparation paid off. As of September 2021, Arizona had recovered the majority of the jobs lost during the pandemic. It has also seen one of the smallest percent change in employment compared with pre-pandemic numbers. Even more impressive, Arizona is one of only five states where unemployment claims are now lower than pre-pandemic numbers. Using VAST helped them get people back to work faster and has become a permanent part of their unemployment program.
Bringing streamlined services to the community
To fully realize a solution to the challenges faced by our public sector customers, we focused on three key areas in which we knew we needed VAST to excel:
- Efficient staff allocation
- Streamlined internal meetings
- Confident constituent interactions
We also knew our customers needed to get VAST online fast, and it needed to work with existing infrastructure without requiring a total overhaul. These areas informed the design of VAST’s features and have allowed us to meet the challenges faced by agencies such as the Arizona Department of Economic Security.
Virtual Agent support and integrations
VAST gives constituents 24×7 virtual agent support powered by Google Cloud’s contact center AI virtual agents. Virtual agents are custom programmed to fit the specific needs of each agency and community they serve. It’s easy to add new options and information whenever an update is needed. Virtual agents can be designed to understand the user’s intent and serve up relevant content for a smooth user experience on both ends of the system. Virtual agents run at scale and offer multi-language support, ensuring they can serve everyone in the community. By pairing these with VAST, constituents can experience seamless self-service.
6 week deployment time
Most of our public sector clients needed a solution yesterday. VAST can be deployed rapidly, taking about six weeks from start to finish, which includes everything–even staff training time.
Integration with Google Workspace and Chrome
VAST securely integrates with other Google solutions, such as Google Workspace and Chromebooks. We work to ensure VAST is fully functional within your existing systems.
Collaboration and support
SADA collaborates with each organization to ensure that the design, development, and functionality of VAST align with their needs. SADA specializes in helping public sector customers migrate to Google Cloud.
Analytics
Application administrators have access to analytic data gathered by VAST and options to customize and add additional datasets.This data helps organizations find blind spots in coverage, fix service bottlenecks, and better organize internal resources. Leveraging this data gives organizations the power to make changes, resulting in everything from a smoother customer experience to cost savings.
To learn more about how Google Cloud has supported Arizona during the pandemic, check out this blog on how their vaccination distribution system leveraged Google Cloud to get the vaccine to more people. For more information on how VAST can streamline a customer experience.
BHI: Embracing Google Workspace and AppSheet to transform the workplace
4265
Of your peers have already read this article.
4:30 Minutes
The most insightful time you'll spend today!
In the last two decades, BHI, once a small construction company in Vernal, Utah, has expanded its operations to dozens of industries in over 25 states. But while the company grew, its technology trailed behind. File sharing and emails both ran off a single server. Editing a document was a grueling undertaking that required an employee to VPN in, patiently download the file, edit it, then upload it again—all from a job site with a limited internet connection. Acknowledging the need for better technology, BHI adopted Google Workspace and AppSheet and transformed its business to be more innovative, productive, and profitable.
Rebuilding collaboration and productivity
BHI first looked to replace its archaic email and file-sharing systems. They found that Google Workspace—as a proven and popular collaboration solution for remote teams and a familiar, preferred platform that most employees use in their personal lives—was the clear choice. BHI migrated its 500 employees to Google Workspace in less than a week. Productivity immediately soared, since employees could collaborate more easily with Google Workspace’s products and access them from any device, from anywhere—even at the construction sites.
For instance, the contract writing process drastically improved with Google Workspace. Version control had always been a struggle—as employees circulated a draft contract from one computer to the next, versions became unruly and randomized, untracked changes popped up, and files went missing. With Google Workspace, the pre-construction, legal, and finance teams can all edit and track changes of a contract from wherever they work. Version control has become a thing of the past, as everyone is always working on the latest version.
By adopting Google Workspace, BHI decentralized its operations and began collaborating in real time across over 150 job sites. Management and IT gained new insights into challenges that they may never have uncovered nor confronted without a cloud-based productivity tool. The IT team also saw an opportunity to overhaul the methods of their deskless workforce, which accounts for 90% of the company. This deskless majority needed to connect directly to the data that influenced, impacted, and comprised their work. They also required more streamlined processes. AppSheet provided the answer to the workforce’s needs, enabling IT to create applications that simplified key tasks so mobile workers could get their jobs done faster and better.
For example, one BHI client required extensive inspections multiple times a day. Before using AppSheet, a BHI inspector would perform the inspection, return to a computer, record the results from paper to a spreadsheet, copy and paste them into a formatted report in a Google Docs, convert the Doc to a PDF, and email the final inspection report to the customer. This manual process took two hours to complete. Now, using AppSheet, the inspector inputs the results on their mobile device while performing the inspection. As soon as the device connects to the internet, it automatically updates the database with the inspector’s inputs, adds the inspection results to a preformatted report built-in Google Docs, and emails the final report as a PDF to the customer. With AppSheet, BHI shortened this inspection process from two hours to six minutes, saving over $50,000 a month in labor. “With Google Workspace and AppSheet, BHI has turned into a digital company with real-time data allowing for real-time decisions, collaboration, and transparency in a decentralized environment,” says
Johnny Hacking, Director of IT.
An easier software choice for faster results
BHI also found that building apps with AppSheet is much easier than using other solutions, such as developing with low- or full-code tools or purchasing third-party products. Because AppSheet is a true no-code platform, anyone can learn to build and maintain apps. Since adopting AppSheet, the BHI IT team has become so proficient with the platform that they have eliminated the company’s previous backlog of software needs. Now, when a new site opens up, IT proactively works with the site managers to understand its unique requirements in order to build a custom app. Start to finish, scoping, and building this site-specific app typically takes less than a week—compared to months with traditional development platforms.
IT team members aren’t the only BHI employees building apps. As Hacking explains, “We have people that aren’t in IT, and when they have an idea we say hey, log into AppSheet, build it out, and then we’ll help out with some final touches on it.”
Empowering employees outside of IT to build AppSheet apps has benefited teams across the company. For example, one team on a solar farm construction project needed to perform inspections of an array of specialized technical equipment with which IT was not familiar. In this case, the solar team, being the subject matter experts, simply built the app according to their specifications. All IT had to do was jump in at the end to help finalize the app—the final product was completely customized to the solar team’s very specific needs. This highlights the benefits of no-code development: on-the-ground experts build and prototype job-specific apps and IT puts the finishing touches on the functionality, all while keeping guardrails in place.
Using Google Workspace and AppSheet also simplifies BHI’s reliance on third-party software. “Our company divisions are so diverse that they each require different software,” says Hacking. “Plus, if we buy a third-party software, we still have to customize it by getting other software, because they don’t play well together. By replacing this software with AppSheet apps, we save a lot of money. And it’s easy to integrate those apps because on the back end, they’re all connected to Google Sheets.”
For the few third-party software products that BHI hasn’t been able to replace, they’ve used Apps Scripts to import the software’s data into Google Sheets, so that their data all lives on one platform. Overall, BHI has been able to free up 10% of its total IT spend by replacing third-party software with Google Workspace and AppSheet apps.
Company culture transformed by technology
“Because we’ve used Google Workspace and AppSheet and it’s been so successful, people are very willing to use them,” Hacking says. “And for a construction company to gain so much trust in these platforms in such a short period of time—that’s huge. Now we’re at the point where employees are asking, ‘What else can we do?’”
Adopting Google Workspace and AppSheet has not only made BHI more productive, but also transformed the company culture. Employees feel empowered to be more innovative and are constantly seeking ways to improve. Simplifying employees’ work has led to a direct boost in morale.
The role of IT has also transformed. As Hacking explains, “In just three years of using these technologies, IT has gone from being support overhead to being proactively brought to the table to take part in the business strategy.” Increased IT visibility and culpability has helped solve business problems and led to increased profitability.
BHI continues to find new ways to leverage Google Workspace and AppSheet to improve business. In response to COVID, they created a timesheet app that allows employees to clock in without touching a device. Most meetings are now held virtually using Google Meet. Fleet maintenance and repairs are all managed with apps. And, of course, the company has better data and insights than ever. As Hacking puts it, “We’re continuing to stay on the cusp of innovation because of Google Workspace and AppSheet.”
How Machine Learning in G Suite Helps Employees of Dalmia Bharat Discover the Next Big Idea
DOWNLOAD CASE STUDY5539
Of your peers have already downloaded this article
5:30 Minutes
The most insightful time you'll spend today!
Creating expense reports, Email management, formatting documents: Your time is caught in the quicksand of formatting, tracking, analysis or other mundane tasks. These are just some of the time-sinks that can affect your—and your employees’—productivity at work. At Google Cloud, this is referred to as “overhead”—time spent working on tasks that do not directly relate to creative output—and it happens a lot.
According to a Google Cloud study, the average worker spends only about 5 percent of his or her time actually coming up with the next big idea.
That’s where machine learning can help.
Machine learning algorithms observe examples and make predictions based on data. In G Suite—Google Cloud’s collaboration and productivity platform—machine learning models make your workday more efficient by taking over menial tasks, like scheduling meetings, or by predicting information you might need and surfacing it for you.
“Smart Reply, (in Gmail) for example, uses machine learning to generate three natural language responses to an email. So if you find yourself on the road or pressed for time and in need of a quick way to clear your inbox, let Smart Reply do it for you,” says Sunil Tewari, Head of Technology and Business Services, Dalmia Bharat.
Messages by Google: Unveiling New Features for AT&T Android Users
3841
Of your peers have already read this article.
1:30 Minutes
The most insightful time you'll spend today!
Today, we’re announcing that we’re working with AT&T to establish Messages by Google as the default messaging application for all AT&T customers in the United States using Android phones. The collaboration aims to help accelerate the industry toward global Rich Communication Services (RCS) coverage and interoperability to offer a consistent, secure, and enhanced messaging experience for all Android users around the world.
“Many AT&T customers have enjoyed the advantages of RCS for years when texting with friends and family,” said David Christopher, executive vice president and general manager – AT&T Mobility. “We look forward to working closely with Google to extend these benefits to even more of our customers as they enjoy richer conversations with others around the world.”
Working together, AT&T and Google will continue the momentum to upgrade SMS with enhanced messaging features offered in Messages, which includes the support of chat features based on the open RCS standard. With Messages as the default messaging application, all AT&T customers using Android devices will get enhanced features so they can:
- Share full-resolution pictures from a recent event or vacation
- Send a higher-quality video of that soccer goal and the celebration that followed
- Know when someone is replying to a text
- Send and receive messages over Wi-Fi or data
- Participate in group chats where it’s easy to add someone else to the conversation, or let someone leave, without starting a brand new thread
In addition to these features, we’re also rolling out end-to-end encryption for one-on-one RCS conversations between people using Messages and people who have chat features enabled.
For years, we’ve been working with the mobile industry and device makers to bring enhanced and secure messaging to everyone on Android. Today’s announcement—that AT&T customers using Android devices will soon be able to enjoy these features by default—is a major step forward.
More Relevant Stories for Your Company
Making Hybrid Work Human: Google Workspace and Economist Impact Survey
Google Workspace recently commissioned Economist Impact to complete a global survey (October 2021)* on the state of hybrid work, including its challenges and opportunities. We already knew that the pandemic had fundamentally changed the world of work, but the survey emphasizes the scale, reach, and longevity of those changes.. Over 75% of
How Did DTDC Express Speed Up Decision-making and Collaboration by 10x—While Cutting Costs?
Among Indian courier and logistics businesses, DTDC has expanded rapidly since its foundation in 1990. Starting with seed capital of less than US$2,000, DTDC has grown to a US$175 million business with operations across the country and internationally. The business is second only to the government-owned India Post in the
Forrester Report: Are You Listening to Your New-Age Cloud Workers?
Today’s modern workers are redefining organizations as we know it. They are no longer tied to a work desk or bound by geographies. And that’s how they ensure that your business is always-on, all the time, everywhere. This, in turn, points to the fact that today’s organizations need to ensure
How Anthos Helps Organizations Implement Multi and Hybrid Cloud Strategy
Organizations have become increasingly focused on using modernization solutions to build competitive advantage, for faster time to market, serve customers better and seamlessly operate in hybrid and multi-cloud environments. Anthos by Google Cloud, a managed application platform plays an important role in application modernization and also in empowering customers to
