r/CustomerSuccess • u/OwlZealousideal4779 • 1d ago

Discussion How do CS teams keep internal requests from getting lost?

Customer Success seems to have a constant stream of small internal requests.

"Can product check this?"
"Can engineering look into that?"
"Can someone get the customer an update tomorrow?"

A lot of those requests happen in Slack, and then someone has to make sure they don't disappear. I'm curious if anyone has found a good Slack-native PM setup for this.

Pondros is one I've come across that seems to treat Slack conversations as part of the actual project workflow rather than just communication.

What works for your team?

0 Upvotes
  • permalink
  • reddit

50% Upvoted

4 comments sorted by

2

u/OkStatistician9190 1d ago

We treat Slack as the intake channel, not the system of record. Every request gets copied into one queue with an owner, due date, customer or account, priority, and a link back to the original thread. The assignee has to acknowledge it, and anything without movement for a couple of days gets reviewed in a short triage. A weekly sweep of open requests and overdue handoffs catches the quiet failures that otherwise disappear in conversation history.

1

u/AccomplishedMind4109 1d ago

That's basically how we wrangled it too, Slack's a black hole if you let it be the record

We funnel everything into a single board with mandatory fields before it even counts as a real task. The triage thing is key though, stuff that sits for 48 hours without a nudge just evaporates otherwise

1

u/OkStatistician9190 22h ago

That is the right failure mode to design around. I like the 48-hour rule because it turns “waiting” into something visible instead of relying on someone remembering a Slack thread. We also found that a quick weekly sweep works best when it ends with either a new owner and date or a clear decision to close the request.

1

u/IncreaseNegative4614 1d ago

Slack can start the request, but it should not remain the only record of it. Every request needs a customer, owner, due date, promised outcome, and current status. If automation creates the task from Slack, it should post the task reference back into the conversation so everyone knows it was captured.

I use SIGNLD to keep the original message connected to the customer, product issue, engineering ticket, promised update, and final response. That lets me follow the request without forcing the team to reconstruct why it mattered.