How we think about our work
Useful advice requires seeing the work before forming a view of it
The principles here are not aspirational statements — they describe how each engagement is actually structured and why it is structured that way.
Back to homeFoundation
What drives this work
Yorozu exists because the advisory market for automation tends to be shaped by the interests of tool providers rather than the interests of the organisations buying or considering them. That gap — between what a vendor-aligned advisor finds useful to say and what would actually be useful to the client — is where we try to operate.
That is a narrow position. It does not make us the right fit for every situation. But for organisations that want an account of their own work that is not shaped by what a platform needs them to find, it is a position worth taking.
Three things we will not do
Accept fees or referral payments from tool vendors whose products we might recommend. The advisory fee is the only revenue from each engagement.
Present findings as broader than the evidence supports. If observation shows that most tasks in a department are better left with a person, that is what we report.
Build systems that remove human override. We document the override logic in every implementation and hand that documentation to the client.
Philosophy
Automation is a tool, not a direction
There is a version of this industry that treats automation as inherently positive — more is better, faster is better, less human involvement is better. We do not share that view.
Automation is useful where the task is structured enough that a system handles it more reliably than a person, and where the consequences of system error are manageable. It is not useful, and can be actively harmful, where the task requires contextual judgment, where variability is high, or where downstream consequences of errors compound before they are caught.
Our work begins with identifying which of those situations applies to each task in your departments — not with assuming the answer in advance.
Core beliefs
What we believe, and why it shapes how we work
Detail is where the truth lives
High-level process maps look clean. Task-level observation often reveals that the clean map omits the exceptions, the edge cases, and the judgment calls that take up most of the actual time. Those details are precisely what determines whether automation will work.
Honest findings serve clients better than comfortable ones
An assessment that concludes "automation would not materially help here" is more useful to a client than one that recommends implementation because implementation is what the advisor is positioned to sell. We would rather deliver a finding that costs less than the engagement than one that leads to an investment that does not pay.
Organisations should leave with something they own
Every engagement produces an artefact the client retains: a task register, a documented constraint set, an evaluation matrix. These are useful beyond the engagement itself. Advisory work that produces only a recommendation — without the underlying material — creates dependency. We prefer not to.
Incentive structures explain most advisory problems
Most advisory outcomes that disappoint clients are not the result of bad faith. They are the result of advisors operating within incentive structures that reward certain findings over others. Understanding that structure — and removing it — is more reliable than asking individuals to override it through effort of will.
Speed of deployment is not a measure of quality
A parallel running period adds time to an implementation. So does a thorough contract review before signing. These steps are friction with a purpose. Systems deployed without them tend to encounter the problems that friction was designed to surface — but later, when they are harder to address.
The person should remain able to intervene
Automated systems are not infallible. The conditions that produced a system's training data do not always match the conditions it encounters in practice. A person who can identify when the system's output is wrong and correct it is not a design flaw — it is a design requirement.
Principles in practice
How these beliefs show up in each engagement
Task Review
We spend four weeks alongside your teams before drawing any conclusions. The task register we produce is a direct output of observation, not of questionnaire responses or process diagram walkthroughs. It records what is actually done, not what is written in a procedure document.
The three-category output — suited, partly suited, not suited — is unusual in this context. Most assessments produce a list of automation candidates. Ours produces a proportionate picture that includes the tasks where automation would be a worse outcome.
Scheduling Implementation
Before building anything, we document the constraints that actually govern your scheduling — contractual hours, skill coverage requirements, individual preferences, and any operational constraints your managers work around daily. The system is built to those constraints, not to a generic template.
The parallel period is not optional. We run both systems together for long enough to identify differences, review them with you, and make adjustments before the old process is retired.
Vendor Selection Advisory
Requirements are defined with you before any provider is contacted. The evaluation criteria are agreed before trials begin. This means providers are assessed against what you need, not against what they are best at demonstrating.
Contract review covers data ownership, portability, and exit provisions as standard items — not as legal details to be skimmed. The written evaluation matrix and notes on indirect answers are yours to keep.
When we recommend not proceeding
It is possible for a task review to conclude that no task in the scope is suited to automation, or that the proportion suited is too small to justify the cost of implementation. When that is what the evidence shows, we say so.
This does not happen rarely. In our experience, most departments contain a mix — and the mix is often skewed toward tasks that a person handles more reliably than a system would. A review that finds this is doing its job.
People in the process
Observation means working with people, not around them
The people who carry out the tasks we observe usually know a great deal about their own work that is not captured in any process document. The informal workarounds, the categories of exception that arise regularly, the tasks that look simple but require judgment — these things are visible to the people doing the work and invisible to anyone who does not spend time with them.
This is why our assessments take four weeks and are conducted alongside your teams, not in a separate space with questionnaires. The engagement is more demanding on both sides because of it. It is also more likely to produce findings that reflect what is actually happening.
What this means practically
Your teams are briefed on why the observation is happening and what it will be used for. There are no hidden assessments or opaque reporting channels.
Findings about individual tasks are not linked to individual people in reporting. The register records the task, not who was doing it when we observed it.
Where teams have observations about their own work that differ from what we have recorded, we revisit the recording. The people closest to the work have the most relevant information about it.
In implementation work, the people who will be working alongside the automated system are included in the design of override and exception-handling procedures.
How we improve
We change our approach when the evidence suggests we should
Not novelty for its own sake
New tools and methods are adopted when they improve the quality of what we produce, not because they signal that we are keeping pace with the industry. The task census methodology has not changed materially since we began using it, because it continues to produce findings that observation confirms as accurate.
Learning from post-implementation patterns
We review the comparison figures from parallel running periods across engagements. Where we see systematic gaps between predicted and actual performance, we adjust the criteria used in assessments. This is a slow process. We prefer slow and accurate to fast and impressionistic.
Scope informed by track record
We do not take on engagement types where we do not yet have sufficient evidence that our methodology produces reliable findings. Expanding the scope of our work is something we do carefully, not in response to client demand for services we have not yet earned the ability to deliver well.
Integrity
What transparency looks like in this context
We tell you when we are not the right fit
If your situation is better served by a specialist implementation partner for a particular platform, or by a larger firm with resources we do not have, we will say so in the initial conversation rather than accepting an engagement we are not positioned to serve well.
This is not generosity — it is how we maintain the credibility that makes our findings worth acting on.
We explain the basis for our conclusions
Every finding in a task register is traceable to observation data. The categorisation criteria are shared with you before we apply them. If you disagree with a classification, we review the underlying data together.
Advisory work that delivers conclusions without the reasoning behind them is asking for a level of trust that has not been earned. We prefer to show our working.
Scope and fee are agreed before work begins
The scope of each engagement, the deliverables, the timeline, and the fee are agreed in writing before any observation or implementation work begins. There are no additional fees for findings that turn out to require more time than anticipated — we absorb that risk, not you.
Data handling is explicit
We document what data we observe, how it is stored during the engagement, and how it is handled at the end. Task registers contain aggregated observations, not personal performance data. This is agreed before observation begins.
Working together
An engagement works better when both sides are involved in it
We ask something of the organisations we work with. Access to the relevant teams during observation. Engagement from the managers whose constraints we need to understand before building a scheduling system. Willingness to review findings that may not confirm what was hoped for.
In return, we do not present a view of your work that is shaped by what we would prefer to find. We do not make findings useful to vendors rather than to you. We produce a written output that you own and can use independently of any future relationship with us.
The effort panel on our home page estimates the client hours involved in each stage of an engagement. We share this upfront because understanding the time commitment on your side is a reasonable part of deciding whether to proceed.
Long-term perspective
What we want an organisation to have, years after an engagement
A clear record of what was found
A task register from a 2025 engagement is still useful in 2028. The tasks change, but the methodology for recording them does not. Organisations that have a baseline can assess how their work has changed without starting a new engagement from scratch.
Systems that are understood internally
Automated systems that only the implementation partner understands are fragile. We document constraint sets, override logic, and exception-handling in terms that a manager without a technical background can read and, where necessary, modify. Organisations should be able to maintain what we build.
Vendor relationships on reasonable terms
Organisations that enter vendor contracts with clear data ownership terms and documented exit provisions have more choices available to them later. That flexibility is worth more than most organisations realise when they sign, and less than it should cost to secure — if the terms are reviewed before signing rather than after a problem arises.
What this means for you
What you can expect from an engagement with Yorozu
You will receive findings that reflect what was actually observed, not what an advisor needed to find in order to justify the next phase of work.
You will retain everything produced during the engagement — the register, the constraint documentation, the evaluation matrix — whether or not you proceed to further work.
You will know the basis for every conclusion, and you can push back on any categorisation we have made. We show our working.
If the findings do not support proceeding to implementation or vendor selection, we will say so directly. We will not propose additional work to soften that conclusion.
If we are not the right fit for your situation, we will tell you in the initial conversation rather than accepting an engagement we cannot serve well.
Any system we build will retain human override, be documented in terms your team can maintain, and be run in parallel with existing processes before any transition is finalised.
Start here
If these principles seem like a reasonable basis for working together, a conversation is a good place to find out whether there is a fit
The initial conversation involves no commitment on either side. We ask about your situation, and you can ask about how we work. If it does not seem like a fit, we say so.
Get in touch