@Lacey Shrum Honestly, the hardest part is that you often can't point to a specific moment and say "that's the one that went wrong", because the cost shows up as a decision you made with worse information, not a decision you know for certain was wrong. We've definitely kept spend on a channel longer than we should have because the real ROI picture didn't catch up to us until a quarter later. Whether a faster number would have changed that specific call, I honestly can't say with certainty, that's sort of the nature of the problem. It's less "one dramatic miss" and more a steady tax on decision quality that's hard to see clearly because you're always comparing to a version of events that didn't happen.

@Lacey Shrum Ha, glad that one landed. Appreciate you digging into this, questions like yours are the ones that actually surface what's really going on rather than the version people tell themselves.

@Kayla Berger At 14 users you're right in the range where the overhead usually pays off, that's typically the tipping point where "everyone just remembers to update the pipeline" stops working. On the KPI side, pipeline dwell time and onboarding velocity are exactly the metrics that expose the gap between a CRM as a system of record versus a system you can actually run the business on. Most native CRM reporting tells you where a contact sits today, not how long they've been stuck there or where the bottleneck is in the sequence. If Hubly's reporting layer can segment by stage duration and flag stalled records automatically, that's worth testing against a real cohort of your slower-moving prospects before you commit. One thing worth asking their team directly: can it alert someone when a prospect has been sitting in a stage too long, or does it only report on it after the fact? Reporting after the fact is useful for retros. Alerting in real time is what actually changes onboarding speed.

@Babette Switzer This is a really useful data point, thanks for sharing the real experience. It echoes what a few other firms have told us too: the tooling around task sequencing and visibility gets a lot better, but the core dependency on someone manually kicking off the workflow doesn't go away. Sounds like in your case the fix ended up being more headcount to cover that gap rather than the tool closing it. Curious whether you've found any workflows where that manual trigger step matters less, versus ones where it's consistently the bottleneck?

@Becky Adams We've tested both across a few different use cases. Broad strokes: Copilot's biggest advantage is that it's already inside Outlook, Word, and Teams, so if your team lives in Microsoft 365 day to day, the friction to actually use it is much lower. People adopt it because it's just already there. ChatGPT Enterprise tends to be stronger for anything more open-ended, drafting from scratch, research synthesis, brainstorming, longer reasoning tasks. The tradeoff is it's a separate tool people have to remember to open, which matters more for adoption than people expect going in. The best model in the world doesn't help if nobody opens the tab. A few areas we've found genuinely useful beyond the obvious: summarizing long email threads before a client call, drafting first passes of routine correspondence for a human to review and personalize, and prepping talking points from meeting notes. Where we've been more cautious is anything client-facing that goes out without a human review step in between, given compliance considerations in this industry specifically. If adoption is a concern on your team, that alone might tip it toward Copilot just because it removes a step. If depth of output matters more than convenience, ChatGPT tends to edge it out in our experience.

@Becky Adams Both handle it reasonably well now, the gap that used to favor ChatGPT for document work has narrowed a lot as Copilot's improved. The more useful distinction at this point is where the document already lives. If it's an email thread or file already in Outlook/Teams/SharePoint, Copilot can pull it directly without you uploading anything, which matters more for adoption than raw model quality does. If it's something outside that ecosystem, ChatGPT still tends to be more flexible with specific extraction instructions. The bigger thing I'd flag regardless of which tool you pick: client statements often contain PII and account details, so before anyone starts uploading real client documents, confirm your org's data handling settings are locked down (no training on your data, correct retention). Worth having IT or compliance verify that explicitly rather than assuming the enterprise tier covers it by default.

@Sami O'Shaughnessy Sounds like you've already covered the most common culprits. A few things worth checking if you haven't: DKIM and DMARC, not just SPF. SPF alone often isn't enough for Yahoo and AOL specifically, both tightened enforcement significantly over the past year and increasingly expect all three authentication methods aligned. If DMARC is set to none or isn't published at all, that's frequently the actual gap even when SPF looks clean. Check your DMARC aggregate reports if you have them set up. They'll show you exactly which sending sources are passing or failing authentication from the receiving server's point of view, which is usually more reliable than trying to reverse engineer it from bounce complaints. Sender reputation is domain-specific and builds independently per provider, so a domain can be perfectly healthy with Gmail and still get flagged intermittently by Yahoo or a specific corporate filter. If it's genuinely intermittent rather than consistent, it's worth asking affected recipients which specific filter or security platform is catching it. Corporate email security platforms (Proofpoint, Mimecast, Barracuda) often have their own reputation scoring separate from the big consumer providers, and that's a common source of the "some people get it, some don't" pattern. Also worth ruling out: if any links in your signature or email body route through a redirect or link shortener, some filters treat that as a spam signal on its own, even if the destination is legitimate.

@Amy Weideman Katherine's breakdown on Tags vs Custom Fields vs Note Templates is spot on. One layer worth adding to the decision: whichever approach you land on, it's worth separating "where do I see the status" from "what happens when the status changes". Tags and fields are great for visibility, letting you filter and report on where a client sits across services. But they're passive, someone still has to go look. If part of the goal (sounds like it might be, given the reporting and operational pain points mentioned) is making sure a service change actually triggers next steps rather than just being visible somewhere, that's worth mapping out separately from the field structure. Otherwise you end up with beautifully organized data that still depends on someone remembering to check it regularly.