Most people do one of those well. Every engagement here needs both — the judgment to work out how a business actually runs, and the discipline to build the system that changes it, inside the tools the client already owns, and hand it over working.
Not a job description. These are the things that decide whether somebody is good at this particular kind of work, and they are the same things the firm measures its own engagements against.
The instinct to map how work actually moves through a business before proposing a system for it. Automation fails on workflow design far more often than on tooling, and the people who do this well ask uncomfortable questions early.
A prototype that impresses in a meeting and a system that runs unattended on a Sunday are different objects. This work is the second one: error handling, escalation paths, and the unglamorous cases that decide whether anyone trusts it.
Every engagement produces a document a client has to act on, and every system has to be explained to whoever operates it after handover. Writing is not adjacent to this work; it is most of it.
Sometimes an off-the-shelf tool genuinely solves the problem, and saying so is worth more than the engagement. A firm willing to lose work by being honest is the one worth hiring.
Engagements are not split between a team that diagnoses and a team that delivers. Whoever takes one carries it from the first conversation through to handover, and answers for how it behaves afterward.
Introduce yourself
Conversations with people who build this way are worth having whether or not they lead anywhere immediately. One email is enough to start one.
What to send
A system you designed and shipped — what manual process it replaced, and what broke after it went live.
That last part is the question that matters. Anything that has genuinely run in production has an answer to it.