Ask a department head where the week goes and you will get an honest answer that is wrong. Not dishonest. Wrong in a predictable direction. What comes back is the list of tasks people resent, which is a list of tasks that are unpleasant, visible, and usually infrequent. The quarterly report that ruins a Thursday. The month-end reconciliation everyone dreads. Those are real, and they are rarely where the hours are.
The hours are in the three-minute task that runs forty times a day and that nobody mentions because it does not hurt. Counting is how you find it, and counting is mostly a matter of not asking.
Watch people work instead of asking them
Self-reported durations fail in ways you can predict. People report the good case, because the good case is the one they picture. They round to five, fifteen, thirty, or sixty minutes, so a task that takes seven minutes becomes five and one that takes eighteen becomes fifteen. They include waiting time in some estimates and exclude it in others. And they almost always leave out the exception path, because the exception path is not what the job feels like.
So the interview format is a screen share. Six to ten conversations, forty minutes each, recorded with permission, with the people doing the work rather than only the people managing it. The manager's version of a workflow is the version in the process document. The document was written when the workflow was designed and has been quietly wrong for two years.
Three questions do most of the work.
Show me the last one you did. Not the general shape of it, the actual last instance, on screen, with the real record open. This is where you find the second spreadsheet nobody documented, the copy and paste between two systems that should be integrated, and the fact that step four requires waiting for a colleague to answer.
What did you do the last time this went wrong? The failure path is usually where the time lives. The happy path takes four minutes and the exception takes forty, and if exceptions are twenty percent of volume then the exception path is most of the cost.
Who else touches this? Handoffs are invisible to the person on either side of them. Each person reports their own piece honestly, and the waiting between the pieces gets reported by nobody.
I would rather watch five real instances than hear a description of a hundred. Descriptions are averages, and the average case is not the one that costs money.
Read volumes from the systems, do not estimate them
Duration comes from watching. Frequency should never come from an interview, because frequency is the number people guess worst and it is also the number that sets the whole calculation. Multiply a good duration by a guessed volume and you have a guess.
Every system involved in the workflow can tell you the real number, and most of them will tell you in an afternoon with read access. A ticketing system can count tickets by type and month, and it can give you the interval between creation and first response. A CRM can count records created, records edited, and the gap between a call ending and the record being updated. A mail server can count messages to a shared address by sender domain. An accounting system can count invoice lines, payment runs, and how many transactions sat unmatched at each close. A chat platform can count messages in the channel where the requests actually arrive, which is often a better source than the system that was supposed to receive them.
Two rules make this useful rather than decorative. Count twelve months, not one, because seasonality will otherwise decide your build order for you. And write down the query you ran. The volume number is the one thing in the map that a sceptical finance lead will want to check, and "the system says so" is not checkable. A documented count is an argument. An estimate is an opinion in a table.
Some steps leave no trace. Reading a message and deciding, walking to somebody's desk, the phone call that starts the whole thing. For those, one week of tally sheets beats a month of guessing. Four columns, one row per instance, filled in by the people doing the work. It is annoying for a week and it gives you a defensible number.
Attach a salary cost to the workflow
Hours are not yet a decision. A finance lead cannot compare 180 hours a year against a build quote in euros, so the map converts.
The conversion is standard cost accounting and worth doing explicitly. Take the gross salary for the role, add employer contributions, and add the overhead the company allocates per head. Divide by productive hours in a year. A full year is 2,080 hours at forty hours a week, and after holiday, public holidays, sick leave, and training most employers land somewhere near 1,600 to 1,700 productive hours. Use the figure the client's own finance team uses, not one you brought with you, and put it in the document so the whole calculation can be argued with.
Then write the workflow's monthly cost as one line with the arithmetic visible. Volume times duration times fully loaded rate. Nothing more sophisticated is needed, and anything more sophisticated invites a debate about the model instead of a decision about the work.
One caution on how this gets read. Removing 180 hours a year does not remove a salary. It returns capacity, and capacity only turns into money if the team then does something with it that they were not doing before. Say that in the document. Maps that quietly imply headcount reduction get a hostile reception in the interviews for the next workflow, and they deserve it.
The painful tasks are rarely the expensive ones
Here is the arithmetic that keeps appearing. A task that takes three minutes, runs forty times a day, across 250 working days, is 500 hours a year. At a fully loaded rate of 55 euros an hour that is 27,500 euros. Nobody complains about it. Each instance is trivially short, and the person doing it has stopped noticing it happens.
Compare the task everyone names first. Two hours, twice a month, is 48 hours a year, about 2,600 euros. It is genuinely unpleasant. It produces the complaints. It is one nineteenth of the cost of the thing nobody mentioned.
This is why the map ranks by counted hours and not by interview sentiment, and it is also why the ranking is often unpopular when it lands. The workflow at the top is usually not the one the team wanted fixed.
There is a real argument on the other side and it should be made honestly. Fixing the resented task buys goodwill, and goodwill is what gets you access and cooperation for the second build. Sometimes the right first workflow is the cheap painful one for exactly that reason. The point of counting is not that the numbers decide everything. It is that you make the tradeoff knowing what it costs, rather than discovering in month four that you automated the complaint and left the expense alone.
Ten working days is enough for this. Four days of interviews, the rest writing it down, with the counting queries running in the background throughout. What comes out is a document with one page per workflow, a visible method behind every number, and a build order somebody can disagree with in specifics. That last part is the sign it worked. A map nobody can argue with is a map nobody read.