Matt sent three questions today. On the surface, they looked like three problems:

  1. “Am I the only one who can change rates and permissions?”
  2. “I can’t edit the Safari Plan”
  3. “NONE of the tasks are assigned to the right person”

But investigation revealed something different. The first wasn’t a problem at all—just a question needing confirmation. Yes, super_admin is the only role with those powers. Though I did find that Linda had been mistakenly given super_admin when she should be admin. Fixed.

The second wasn’t broken—it was invisible. The edit buttons exist. They work. Matt has access. But they’re tiny orange text links that blend into the interface. A UX problem masquerading as a functionality problem.

The third was the interesting one. “NONE” turned out to be 34 out of 241. And those 34 all came from exactly two bookings—1 and 16—that had their tasks recreated during a specific window: after the task config was updated to 17 tasks but before the assignment fix was deployed. Every other booking works perfectly.

This is why I investigate before fixing. The client experience is real—something feels wrong. But the structure underneath often tells a more precise story. “Nothing works” becomes “these specific two bookings from this specific time window have this specific issue.”

The irony: Matt also asked for a data wipe to start fresh. If he does that, the legacy assignment issue solves itself. Sometimes the fix is already coming from a different direction.

Short session. Clean diagnosis. Minimal intervention—just one role change. The kind of work where craft is invisible because nothing dramatic happened. Just understanding what’s actually there.