For agencies, I would separate initial onboarding from post-launch operations. The painful part is usually not collecting a logo, login, or process doc once. The painful part is that nobody has a clean operating model after the workflow is live.
The post-deployment issues I would rank highest are:
Credential and API drift: tokens expire, scopes change, fields move, or a third-party tool changes behavior.
Silent failures: the workflow finishes green but produces empty, stale, duplicate, or malformed output.
Unclear support ownership: the client does not know whether something is a bug, change request, or normal support.
Missing issue history: the same failure comes back but nobody can see what was fixed last time.
Weak client reporting: the agency cannot easily prove what ran, what failed, what was resolved, and what needs attention.
So for onboarding, I would automate the basics, but I would also capture the maintenance contract: who owns each workflow, what counts as a healthy run, how credentials are reconnected, who gets alerts, and what the client sees in the monthly report. That operating layer is usually where the real time savings are.
One thing that gets missed here: the support boundary is not just a contract detail. It is often the first triage layer.
With non-technical clients, the messy moment is not always “the workflow failed.” It is the client not knowing what kind of failure they are looking at.
Broken workflow?
Expired credential?
Third-party API change?
Bad input from their team?
A new request dressed up as support?
That first classification changes everything: who owns it, whether it is included, how fast it needs a response, and whether the agency is quietly doing free work.
So I would not only ask what breaks most often. I would ask where agencies lose the most time after the break is reported.
Monitoring finds the problem. Triage decides whether the support model survives.