The plan is not "automate it". The plan is "write it down"
Process automation gets bought the wrong way round more often than not. Someone senior sees a demo, likes what a tool promises, and signs off a build against a process that has never been written down in one place. By the time anyone asks what the automation was actually supposed to do, the only description of the process lived in the heads of the people doing it, and they have since moved on, changed the workaround, or left. The deliverable that actually protects an operations director is not the automation. It is the written process map that comes before it.
Automating the process starts with the map, not the build
A back-office process, such as onboarding a new starter, chasing a compliance document, or moving a timesheet from a spreadsheet into payroll, is rarely one clean sequence. It is a sequence plus a set of exceptions, a set of people who each hold a piece of it, and a set of judgement calls nobody wrote down because everyone involved just knew what to do. Before any of that can be automated, it has to exist outside those people's heads, as a document that names every step, every handoff, every exception and every system it touches.
That document is the first deliverable MSD Systems produces on an engagement, not an afterthought to it. It gets agreed in writing before a line of the build starts, because a process map that both sides have signed off is the only thing that later lets anyone check whether the build actually did what it was meant to do.
Why automation bought before the map cannot be defended afterwards
If the process was never written down, the automation cannot be checked against anything. A finance director asks what changed and gets an impression, not an answer. A new starter asks how the process is supposed to work and gets shown the tool, not the logic. Then the tool breaks: a form changes, a supplier renames a field, an exception nobody documented turns up for the first time in production. Nobody can say with confidence whether that behaviour is a bug or was always the intended path, because there was never a version of the process to compare it against.
This is the argument for writing the process down before automating it, not after. A map is the only artefact that survives staff turnover, tool changes and time. Automation without one is a black box that happens to work until the day it doesn't, and on that day there is nothing written to debug it against.
Mapping a back-office process with the people who run it
A process map that is worth anything is written with the people doing the work, not about them from a spreadsheet of assumptions.
Start with the person, not the org chart
The org chart says who owns a process. It rarely says who actually runs it day to day, and those are frequently different people. Mapping starts by sitting with whoever touches the process most, the person keying the timesheet, chasing the missing document, closing the onboarding pack, and walking every step with them in the order they actually happen, not the order a policy document implies.
Write down the exceptions
The clean version of a process, where input arrives, gets checked and gets actioned, is the least useful part of the map. What breaks automation later is the exception nobody thought to mention: the client who always sends the form the wrong way round, the supplier whose reference number format changes twice a year, the record that needs a manager's judgement call rather than a rule. Every one of those gets written down as its own branch, with what happens next and who decides it.
Get sign-off, then treat it as the reference
Once the map exists, it goes back to the people who described it and to whoever owns the outcome, for correction and agreement. From that point the map is the reference the build works against, and the reference any later question about the automation's behaviour gets checked against. Not memory, not the tool's own logs: the document both sides signed off.
What a written baseline is, and what it is not
A baseline, in this context, is a written, agreed description of how the process runs today: the steps, the systems it touches, the exceptions, the people involved and the handoffs between them. It is not a number. MSD Systems does not put a saving, a percentage or a time figure into a baseline document, because nothing has been measured on a client's process yet, and a number without a measurement behind it is a guess dressed up as a fact.
What the written baseline does instead is give both sides something concrete to check the finished build against. Does the automation cover every step in the document? Does it handle every exception that was written down? Does anything happen now that was not in the map, and does anything in the map still happen by hand that was meant to stop? That comparison is possible because the baseline is specific and dated and agreed before the build starts. Without it, whether the automation worked is a matter of opinion.
Where an AI digital worker fits once the map exists
Some of what a process map surfaces is a candidate for straightforward automation: a fixed rule, applied the same way every time. Some of it is a better fit for an AI worker, something that has to read a document, check it against a rule, make a judgement inside defined limits, and escalate what it cannot resolve to a named person rather than fail silently. Which parts fall into which category only becomes clear once the process is written down in enough detail to see the actual decision points, not the ones a policy document assumed existed.
No AI worker has run for a client yet. We scope it and discuss it; we do not claim it is running for a client. Where the map points to a role for one, that scoping happens in the open, against the same written process, before anything is built. The automation and AI service page sets out the wider approach: find the work, map the process, automate it, check it.
The same discipline, wherever the process sits
The mapping approach does not change by sector; the exceptions do. A recruitment or staffing back office has its own version of this problem, in onboarding packs, compliance chases and timesheets that move between a spreadsheet and payroll, each with exception patterns worth writing down before anyone automates them. The recruitment and staffing page sets out how that administration gets handled once it is mapped. The principle stays the same wherever the process sits: write it down first, agree it in writing, then decide what gets automated outright and what needs a worker's judgement.
Start with a scoping conversation, not a demo
None of this requires committing to a build to find out where it goes. A scoping conversation is where the process gets described, the exceptions get listed, and both sides agree in writing what the baseline actually is, before anyone talks about what gets automated or how. A first engagement covers one named process, not a portfolio, so the map stays specific enough to check the build against later.
If a back-office process has never been written down properly, that conversation is the place to start, not a demonstration of a tool that has not yet seen the process it would be automating. Talk to MSD Systems about the process worth mapping first, or read how bespoke back-office systems get built once that map exists.
No AI worker has run for a client yet. We scope it and discuss it; we do not claim it is running for a client.
A few useful questions.
What is business process automation?
How do you map a business process before automating it?
What is a process baseline, and why do you need one before automating?
