The Shadow Workflow of Loan Processors
The formal system is not the whole job. I want to find out what the rest of it costs.
What I am looking into
01Loan processing has formal software. Origination systems, document portals, underwriting tools. That software describes a workflow, and companies buy it based on that description.
My working assumption is that the described workflow is not the whole job. Around it there is a second one made of spreadsheets, separate portals, documents that get re-keyed, copy and paste, manual verification, reconciling systems that do not talk to each other, and checks people do because they have learned they have to. None of that shows up in a product demo. All of it is somebody's afternoon.
That second workflow is what I am calling the shadow workflow. I want to know how big it is, which parts of it actually hurt, and whether any of the pain is worth money to get rid of.
Why I care about this
02It comes straight out of Peko. I found a technically interesting problem, built for it for five years, and the interesting part turned out not to be the same thing as a good opportunity. I would rather not do that again.
So this time I am going the other direction. Find real work that real people do, understand it properly, and only then ask what software could do about it. Loan processing seemed like a reasonable place to try that. It is document heavy, regulated, repetitive, and it happens inside businesses that can pay for software.
I want to be clear about what this is, though. It is not a company. There is no product and no prototype. It is research, and it might end with me concluding there is nothing here worth building. That would still be useful, and it would be a lot cheaper than the last time I found that out.
Notes
03What I do not know yet
04Basically all of it. I would rather say that than dress up a guess as a finding.