There is a lot I genuinely value about it. It’s incredibly customizable. It has important functionality built in, including things like Roles, Permissions, and the ability to log in as another user. It’s also deeply integrated with tools like HubSpot and DocuSign. And because our engineering team has built date-partitioned tables off the underlying data, I have historical snapshots I can go back to whenever I inevitably need to investigate what changed.

On the other hand, a coworker recently described one of Salesforce’s biggest problems as “click fatigue.” Ever since he said it, I haven’t been able to unthink it. Once you notice the clicking, you notice it everywhere. Sales feels it on the front end, where creating a single Opportunity can take no fewer than 20 clicks. I feel it on the back end, where I spend a lot of time in Setup acting as our de facto Salesforce admin.

And then there are the quirks. I’ve spent an unreasonable amount of time figuring out ways around them, so partly for context and partly because it is cathartic for me to write them down, here are a few:

• Validation rules don’t work particularly well across objects. If you want to restrict a field on the Opportunity Product only when the Opportunity moves to Closed Won, a validation rule can’t do it.

• Once you have an Opportunity Product and want to change the Product, you can’t. You can’t clone it either. Your only option is to rebuild the Opportunity Product from scratch.

• The Start and End Dates on the Opportunity Product don’t talk to the Opportunity Schedule.

• Salesforce seems to anchor everything on Close Date; it is even a hard-coded required field. At the places I’ve worked, Close Date often hasn’t been especially meaningful. I’ve always looked at revenue based on when it is scheduled in the Opportunity Product.

• Related Contacts are a mess. It’s very easy to end up with duplicate Contacts, including situations where one is a Related Contact and can’t easily be merged.

• Reports and dashboards have all sorts of limitations.

For years, the answer to problems like these has mostly been some combination of configuration, custom development, process, documentation, and occasionally just accepting that Salesforce works the way Salesforce works.

Lately, though, I’ve started to think there is another option. Importantly, that option is not vibe coding an entirely new CRM.

A few things led me here. First, I organized an AI hackathon at work, and I was impressed by the creative artifacts our Sales team built. They came up with new interfaces that pulled together disparate information into something much more actionable. Second, I watched a ChatGPT Work webinar where their Sales team was accessing and editing information about their book of business without constantly jumping into Salesforce and other tools. Then I discovered that it was possible to collaborate on Claude artifacts.

Together, those ideas became the premise for something I’m calling our Sales Hub: a Claude artifact that pulls together the information Sales wants at their fingertips without all the click fatigue.

Before I started building it, I had Codex mock up the idea for me. This is actually a little trick I’ve picked up while working with these tools. I really like the look and feel of Codex’s designs, so sometimes I’ll ask Codex to take the first pass at an interface, then hand that design to another tool like Claude or Replit as a starting point.

Below is the original mockup Codex made for my Sales Hub.

The mockup was the easy part. Actually hooking everything up has taken more time. But now that it is starting to work, it is pure joy, at least to me.

I don’t know if I should admit this, but I once pulled an all-nighter building a Tableau dashboard for my Sales team. I love this stuff. And compared with the old way of doing it, this feels like a dream. The level of customization and ease isn’t even comparable.

My primary goal with the Sales Hub is to avoid a world where everyone builds their own bespoke AI dashboard and burns a bunch of Claude usage recreating roughly the same thing. Instead, I want to package the information people need in a way that is useful, intuitive, and not overwhelming.

But I also have an ulterior motive: I want clean data. The holy grail of any Revenue Operations person.

Historically, the options for getting that information have not been great. Sometimes I can build a validation rule. Sometimes, because of Salesforce’s limitations, I can’t. And when I can’t, the fallback is usually some version of me finding the problem, messaging someone, and asking them to go into Salesforce to fix it. Which, of course, means more clicking.

So I built alerts directly into the Sales Hub. Each page in the left-hand menu surfaces the problems relevant to that section. On the Opportunities tab, for example, it calls out Opportunities that are missing Products. On the Billing tab, it flags Closed Won Opportunities that were sold at a CPM but are missing the CPM Rate.

Then there is an Action Center that pulls all of those alerts into one place. And this is the part I’m especially excited about: the items can be fixed inline. Instead of me tracking someone down and saying, “Hey, can you go find this Opportunity, open it, navigate to the right place, and update this field?”, the Sales Hub can simply say: “Here are the five things that need your attention. Fix them here.”

That feels like a small change, but I think it represents something much bigger.

For years, I’ve thought about how to make the CRM experience better: better configuration, better dashboards, better processes, better data hygiene. Now I’m wondering whether the more interesting opportunity is to leave Salesforce doing the things it is actually very good at and build a much better experience on top of it.

Salesforce can still hold the data. It can still manage permissions, connect to other systems, and enforce the business logic. But maybe the average seller doesn’t need to spend nearly as much time inside the Salesforce interface itself.

That distinction feels increasingly important as AI tools get better at both reading from and writing back to our systems. The question becomes less, “How do I make this system easier to navigate?” and more, “What is the simplest possible experience I can build for the person trying to get something done?”

After years of fighting with Salesforce’s limitations and chasing the dream of clean data, I can finally see a light at the end of the tunnel.

The added challenge here is just how quickly everything has been moving. Even when it comes to this Substack, there have been multiple times when I wanted to write about something, only to find that it had already changed by the time I sat down to do it. Everything really is becoming suddenly automated.

Over the past 6 months, I’ve organized three distinct initiatives to drive AI education and adoption across the company:

• Company-wide AI 101 training

• Function-specific training tracks

• An AI hackathon

Company-wide AI 101

Even though the tools themselves have significantly evolved, I believe the overarching content in my AI 101 deck still holds up. It covered what is AI, the main tools, basic examples, responsible use, and where AI may be heading.

The goal was to help everyone understand how AI fundamentally works and give them the basic building blocks to jump in. Hopefully, even the more experienced people learned at least one new thing.

Function-specific training tracks

Next came separate training tracks for Engineering, Product and Design, Customer Experience, Sales and Partnerships, Marketing, Security and IT, and Finance, Operations, People and Legal.

I co-led the Finance, Operations, People and Legal track, but I also sat in on most of the others. Each followed the same basic outline—tools and setup, best practices, and AI in action—but the content varied substantially by function.

In my own session, I learned about Google Apps Script and interactive Claude artifacts. In the Consumer session, I learned about Replit and just how accessible it has become to build and publish your own mobile app. In the Security session, I learned that you should apparently never threaten your chatbot—unless you want it to blackmail you.

I came away wishing each track had included more hands-on-keyboard time. Watching someone show off what they built can be inspiring, but it isn’t the same as building something yourself.

The AI hackathon

The third piece was an AI hackathon, designed to create exactly that hands-on opportunity.

The premise was simple: dedicate a full day to building automations that make our work faster, smarter, or better.

Giving everyone the dedicated time was important. It is difficult to step away from the current process long enough to rethink it. Even when someone knows a task could be automated, the daily work keeps arriving. The hackathon created protected time to put pen to paper, roll up our sleeves, and actually build something.

About a third of the company participated. It was especially exciting to see strong participation from Sales, a group that is often underrepresented in traditional hackathons.

We held a dedicated build day, followed by a demo day one week later to accommodate time zones and scheduling conflicts. Each person or team added their project to a shared presentation, and we awarded prizes in three categories:

• Biggest Time Saver: The automation that could win back the most hours

• Biggest Unlock: The most impactful solution to an existing bottleneck

• Most Likely to Scale: The project with the greatest company-wide potential

The projects included Claude Skills, Slack bots, Claude artifacts, Convey agent jobs, and automations that combined multiple tools. I even used AI to build the scoring workbook for the judges.

It was genuinely inspiring to see what everyone created. It was also valuable to uncover similar projects being developed by different teams that should be collaborating.

Keeping the momentum going

Outside of those three initiatives, I also created a Slack channel (#ai-tips) and started hosting weekly AI office hours.

The office hours were created as a place for people to get advice when they aren’t sure how to approach something. Increasingly, the question isn’t whether a task can be done with AI. It is which of the many possible approaches makes the most sense.

The sessions have become a helpful forum for talking through those options. Some people even come simply to listen, hear what others are trying to build, and learn more about how AI can be used.

My biggest takeaway is that the best way to learn AI is to put it into practice, push the boundaries of what you believe is possible, and create regular opportunities to talk with other people who are learning alongside you.

I’ll end with what I’ve told my coworkers throughout this process:

I’ve always taken notes by hand during the day. I’ve read that writing things down helps with memory and problem solving. For me, it is calming. Listing out all the things I need to do makes them feel manageable, even when the list fills a whole page.

It also lets me draw things out in less orderly ways: arrows, boxes, little clusters of thoughts that do not need to be presentable. This has become especially useful as I spend more time working with AI tools and thinking through how data connects across them. Sometimes, in order to figure out how the solution should work, I need to draw the mess first.

Recently, I’ve especially enjoyed ditching my pens for a #2 pencil. I’ve stationed my childhood electric pencil sharpener on my desk, and there is such a specific joy in sharpening a pencil: the sound and the tiny ritual of it. Even my four-year-old son delights in using it.

At the same time, I’ve gone in the opposite direction too: I’ve started verbally recording my thoughts.

When I’m out walking the dog, I don’t really want to be typing into my phone. But walking has become some of my best thinking time. Ideas pop up. Random connections make themselves known. In the past, I’d get home and try to remember what I had been thinking about, and by then the thought had usually lost some of its shape. Now I just record myself using Wispr while I walk.

Voice lets me get a lot of context out of my head quickly: the background, the constraints, the half-formed thought, the thing I’m trying to say but haven’t organized yet.

Typing all of that can turn into a long back-and-forth where I’m slowly feeding the tool context I already had. Voice is messier, but faster. When I get home, I copy the transcript into Claude and let it help structure the mess, which is much better than trying to recreate it from memory while also avoiding an accidental command + return.

What I like about both habits is that they help me give AI better inputs.

The pencil helps me see the shape of a problem before I ask a tool to help with it. The voice memo helps me capture the raw material before it disappears.

One is slow and visual. One is fast and verbal.

Both help me process and record my thoughts. Both help me catch ideas before they disappear. And both, hopefully, will spare me from future carpal tunnel issues too.

This whole conversation is also not new. The “build versus buy” topic is one every tech company asks itself at least once. AI just makes the build side feel a lot more tempting. This brings me to my far-from-comprehensive, highly debatable Build vs. Buy table:

Even those in the “Build” camp will be bought

I also don’t believe everything here in my “Build” camp will definitely be built. These companies are going to try hard to find ways to keep their customers. And even if something would be possible to build, it might still make sense not to. For instance, penetration testing would be straightforward enough to do on your own. But for SOC2 and other compliance processes, you may need to show certification of completion. A homegrown test might not “pass.” With a website builder, if the website is relatively small, sure. But if it’s large, you probably don’t want to worry about bugs, SEO, templates, analytics, and all the other things that come with maintaining it. For a sales enablement tool, if you’re using it externally with customers, then you’re probably going to want to stick with it. But if you’re truly only using it as the source of truth for your collateral, AI could probably sub in.

Systems of record feel different

In terms of “Buy,” there’s definitely a theme around systems of record. I’m closest to Salesforce, and I have to say: I don’t think it’s going anywhere. I am very familiar with how to build things in Salesforce and all the dials and knobs on the backend. I think there is so much more there than people realize. To rebuild Salesforce would require thinking through and accounting for so many requirements: object and field customizations, permissions, workflows, integrations, admin controls, change history, and all the random edge cases every company accumulates over time. Obviously it’s possible. I worked at Google, and they did roll their own. While I was there they called it GRM, short for Google Relationship Manager. There was a whole team dedicated to developing and supporting the tool, and even then, it still wasn’t perfect. That’s what people underestimate: the initial build is only one part of the work.

I do think an upstart may steal share from Salesforce, but even that won’t happen overnight. It has to have the table-stakes functionality and flexibility that Salesforce has while getting everyone excited about its AI-forwardness. For instance, Gong recorded meeting transcripts before, but Granola came out and made a lot of people realize there could be a lighter, more AI-native version.

My build-vs-buy consideration set

Obviously, the classic build-vs-buy question is partly about whether something is strategic enough to own. I still think that matters. But with AI making the initial build feel easier, I think the more interesting question is whether you actually should own all the software you’ve been buying.

So I’ve distilled what I think the principles are for deciding whether something should be bought or built. I’ve come up with five dimensions. If it passes all five, then sure: build it.

Complexity: If it would take a lot of time and technical know-how to get all the requirements and details right, then buy. Otherwise, if it’s relatively simple to build and maintain, build.

Criticality: If it creates real risk when it breaks, then buy. If downtime or bugs would be annoying but manageable, building may be fine.

Permissions: If you don’t need to manage user access levels, great. Build. If you need one or two role types, maybe you can still handle it. But if you need multiple permission levels, then buy.

Integrations: If there are no integrations needed, great. Build. If the desired integration has an open MCP or an API, okay, maybe build. If the tool requires an integration that involves business development or is deeply tied into other business-critical systems, just buy.

Credibility: If you need an external certification, audit trail, or third-party stamp of approval, then buy. A homegrown version may work internally, but it may not be enough externally.

So, will today’s software companies become dinosaurs?

I wouldn’t start planning a dinosaur museum.

I think companies will build more of the lightweight, internal, low-risk workflows they used to buy. And they will still buy the systems where reliability, permissions, integrations, compliance, and maintenance matter.

The build-vs-buy question is still going strong. AI just made the answer more interesting.

But for me, it might as well have been.

I vaguely remember stumbling upon it when trying to solve a problem and seeing someone on a forum suggest it as the solution. But I didn’t know how to write the actual scripts, and it felt like it was simply not built for people like me.

Until now.

I learned last week that with AI, I can describe what I want automated, and ChatGPT can build the code for me. It writes the script, explains how to implement it, and helps me troubleshoot it.

And to be clear: it did need a few iterations.

At least for me, the code was never perfect on the first try. I would run it, get an error or check the output against what I expected, and then bring the issue back to ChatGPT. It became a back-and-forth process: describe the goal, test the script, find the problem, refine the script, and test again.

I just had to know how to recognize when something wasn’t working. Being a good QA tester and being detail-oriented is key.

To hopefully inspire you, I wanted to share two Google Apps Script automations I recently built, what I learned from each one, and why I think this kind of lightweight automation is suddenly much more accessible.

First, a quick overview

The general process looks like this:

1. Go to Google Apps Script at script.google.com and create a new project.

2. Paste in the code that AI gives you. Clear out the default function myfunction() {} code first.

3. Save the script with Command + S.

4. Toggle to the main function and click “Run”. If you don’t know which one is the main one, AI can tell you. While there may be several functions in the code, you generally only need to manually run the setup or “run” function once.

5. Approve the permissions. You may have to click through some discouraging pop-ups.

6. If you also want your script to run on a schedule, you’ll also need to set up a trigger either by running an install function or clicking on the Triggers icon in the left-hand menu bar and setting it up manually.

Once you finish all these steps, you should be all set. Don’t be surprised when you see your Apps Script show up in your Google Drive.

Automation #1: Auto-deleting files from Google Drive

Sometimes I create a document, sheet, or file by accident and immediately know I do not need it.

When you are inside a Google Doc or Sheet, there is not a simple one-click “delete this file” button. So for years, my workaround has been to rename the file something like “Delete” or “Delete me” and delete it later when I see it sitting in my Drive.

I also use IMPORTRANGE in Google Sheets a lot. When you use this function, it automatically saves the raw file to your Google Drive. It’s unavoidable. So over time, my Drive accumulates a bunch of clutter.

Thus, I wanted a script that would automatically look for files with names like “Delete,” “Delete me,” or common names of files that I typically import, and move them to trash.

The first version seemed like it was working. Then, all of a sudden, it failed.

I pasted the error back into ChatGPT, and it suggested that the script might be trying to search through too many files and timing out.

That made sense. Most of the files I wanted to delete were not buried in a folder; they were sitting in the root of my Google Drive. So I told ChatGPT to update the script to only look there. That solved the problem, and I’m happy to retire my periodic Google Drive “spring cleaning” routine.

Automation #2: Scheduling a time to walk my dog each day

The second automation had to do with my calendar.

I wanted a script that would schedule time to walk my dog, Fred, on days when I would otherwise forget to protect the time.

Here were my initial requirements:

• Run automatically every Thursday around 9 a.m. using a time-based trigger.

• Schedule a 30-minute “🐾 Walk Fred” event on my Temp calendar for the upcoming Tuesday, Wednesday, and Friday.

• Randomly pick event times between 10 a.m. and 5 p.m. ET.

• Avoid conflicts with events on both my work calendar and personal calendar.

• Skip the day entirely if I appear to be out of office or on a company holiday, based on keywords like “OOO,” “vacation,” “PTO,” or “holiday” in event titles or descriptions.

ChatGPT also suggested one additional requirement:

• If no free slot exists between 10 a.m. and 5 p.m., fall back to 8 a.m. ET.

That was a good suggestion, so I added it.

Then, after testing the script a few times, I’d find another preference I had not thought to mention.

For example, I did not want the event to start at some random time like 10:07. I also did not really want the walk dropped randomly into the middle of an open slot. I wanted it to abut existing meetings, so it would create a cleaner block on my calendar instead of fragmenting my day. And I realized my calendar had declined events that were still showing up and blocking the script from scheduling time.

So I added:

• Start times should always snap to :00, :15, :30, or :45.

• Prefer slots adjacent to existing events, with no gap between meetings.

• If no adjacent slot is available, fall back to a random available slot.

• Declined events should be ignored.

• Tentative or unresponded events should still be treated as conflicts.

Without all the extra logic, I’m not sure this automation would have been any better than what I had already been doing manually each week. But now I feel confident that I can take this off my plate.

Final thought

This was seriously so easy. I can’t believe I went 10+ years without using it before. At this point, the real limitation is not the tooling. It’s my ability to think of more good use cases.

Hi, I’m [your full name]. I used to be a [first job], but I somehow landed a job at Pinterest as a [dream job]. I manage the sales team that works on the [a brand you love] business. Did you know they sell [noun]? Their results are [adjective]. At this rate, I think we should open an office near their headquarters in [where you grew up]. The office would be [adjective]. We’d stock the kitchen with [your favorite food], let employees bring their [noun] to work, ban all [pet peeves], and go [verb-ing] every Thursday. The team will definitely blow their goals out of the [noun]. And when they do, I’m taking everyone on a trip to [the last place you went on vacation].

It worked well because people could be funny without having to think too hard, and the final read-alouds gave everyone an easy way to share a little about themselves.

I’ve now turned it into a GPT, so people can just plug in their answers and get the full paragraph back, ready to read. It’s free in the GPT Store in case you want to use it for your own team.

In particular, there are two functions I still think are underused, especially for anyone who wants to create lightweight workflows:

• IMPORTRANGE

• QUERY

Let me share a recent example of why these functions are so useful and how nicely they can work together.

A real-life use case

Our Associate General Counsel keeps a running list of what they’re working on in a Google Sheet, with items grouped by category.

Recently, our Partnerships team wanted visibility into that queue so they could check in on the status of their deals without constantly pinging Legal.

The QUERY function is basically SQL for Sheets. You write a SELECT statement over a range of cells.

On a separate tab, I filtered the master list down to just the Partnerships-related rows:

=QUERY('Full List'!A:I,"SELECT A,B,C,D,E,F,I WHERE A = 'Contract: Partner' ORDER BY D")

No surprise: if you try to include a column in the SELECT statement that’s not in the provided range, the formula errors out.

At that point, I could have simply shared the AGC’s sheet and restricted access to the “Full List” tab. But that doc had other tabs, and it’s cleaner and safer to keep the “viewer” version separate.

That’s where IMPORTRANGE comes in. It pulls data from one Google Sheet into another automatically.

In a brand-new Google Sheet, I imported the filtered tab:

=IMPORTRANGE("https://docs.google.com/spreadsheets/XX","Partnerships!A1:J200")

The result was a dedicated sheet the Partnerships team could bookmark and check anytime for the current status, with no extra work needed from Legal.

Note: when you use IMPORTRANGE, Google Sheets will return #REF! and prompt you to “Allow access.” That’s normal.

What AI suggested

I was happy to find that AI (Claude, in this case) landed on the same solution I did.

It first suggested creating a Partnerships view using QUERY or FILTER. Once I explained that the source spreadsheet had other tabs I didn’t want exposed, it added the next step: use IMPORTRANGE to pull that filtered view into a brand-new sheet.

I hadn’t discussed this exact scenario with Claude beforehand, so this wasn’t it just parroting my own answer back to me.

A quick note on Gemini in Sheets

Since Gemini is built into Google Sheets, I’m really curious to see where this goes.

I’ve been testing it out, and it’s pretty cool that you can ask it to do things you previously would have had to do manually. For example, I asked it to conditionally format a column, and it did.

But it’s not fully there yet. I also asked: “Can you make a tab isolating just the Contract: Partner values?” The result was nonsensical.

Gemini will surely make workflows like this easier to build in the future. Until then, knowing a few formulas is still a real advantage.

I’ve owned terriblyorganized.com and suddenlyrevops.com for years, always intending to publish under them. But now, Suddenly Automated is the one that fits. It captures exactly what I’m trying to do: take the stuff I’ve learned and revisit it with an eye toward automation.

A lot of this isn’t on the internet. I’ve searched. Many times. And when the answer wasn’t there, I’d end up going internal: asking a colleague, thinking back to what a previous company did, or building the solution from scratch.

AI makes this more worth documenting, not less. In theory, it should be able to answer the exact questions I used to hunt for. In practice, it still needs structure: clear processes, good examples, and a source of truth. So this Substack is me building a library of how I work: the approaches, workflows, workarounds, and the “gotchas” that get learned, forgotten, and re-learned on repeat, so both humans and AI can use them. And while part of this is about creating a reference for AI, part of it is about pressure-testing what I’ve always done and asking: is there a better way now?

I also genuinely love this stuff. I like documentation. I like making things repeatable and efficient. I like building workflows that don’t collapse the second one person goes on vacation. One reference-check question I always come back to is: “What did <NAME> do at your company that still exists today?” That’s the kind of impact I want to have.

Most posts will be about RevOps. Some will fall outside of it. But all will be about the ways I’ve tried to organize or automate the chaos around me.

Good stuff ahead.