Hey @augmented!
As someone who has implemented Airtable for a few teams of varying sizes, I empathize with the struggle of driving user adoption.
This might be a bit dense, but faced with what you’ve described, I think of two things:
First: Integration
I would also leverage a tool like Make to create data channels from your team’s existing tools into Airtable.
You want Airtable to be your single source of truth.
A fundamental principle in maintaining clean data is avoiding what I call cross-talk.
You want to prevent systems from talking to one another.
It would help if you had them route to your source of truth, where their data can then be routed to other systems.
There is a myriad of reasons why this is beneficial, but the diagram below gives you an idea of how messy it can become when everything talks between each other.
Cleaning it up can bring you into a structure like this:
While Gmail, Zoom, and your other Google apps might have native integrations, the data they’re working with is always in your source of truth.
Make can coordinate and automate getting that data into Airtable, but it will always end up in the same place.
Now, in terms of actual implementation, from what I’ve seen, @ScottWorld loves Make. Scott can probably provide a bit of insight on that front.
Depending on your level of comfortability with scripting/JS, it is also possible to have emails forwarded via Make (or your email client, depending on the client) hit a webhook in Airtable, have a script evaluate the payload, and then run through a Find → Update → Create setup to handle the bulk CRM automation.
Secondly: Break Down The Cost-Benefit Analysis
This can be the tough love approach.
Anytime you introduce a new tool or make a process change, there will be people that inevitably don’t like it.
The key is to have people understand the ways that a change benefits them.
Sure, it’s a change in where they click or what apps they have open, but what does that change allow them to do now that they couldn’t do before.
Is that valuable to them?
Answering that question is critical to driving adoption.
It’s also vital from a business perspective.
:no_entry: What’s below is a bit more in the line of thinking behind product management and business operations than anything else. :no_entry:
Depending on your relationship with your users and stakeholders, it would be beneficial to consider how you can build user engagement by highlighting the business value of the change or product.
I like to think about actual metrics.
Let’s say it takes 10 minutes to work through a customer task and finish a workflow.
An IC spends 1 minute working on each sub-task, but they lose 25 seconds doing duplicate data entry and hopping between systems.
Take that math, and you realize that they’re losing over 4 minutes doing what should be a 6-minute task.
Scale that to 45 customers in a single 7.5-hour workday.
- 10 minutes per customer = 7.5 hours (450 minutes).
-
Total Time Lost = 3 hours (180 minutes).
- Actual Productivity Time = 4.5 hours.
So… in a week, you expect 37.5 productive hours from an IC, but the actual number is only 22.5 hours.
In a 250-day work year, you expect 1950 productive hours, but the actual number is only 1170 hours.
Of course, those are numbers in a perfect vacuum, and nobody spends their entire day doing the same task, but it’s a great way to get a sense of the impact something might have when implemented.
