Values · Principles · Approach
What we believe, and how that shapes what we do
The way we approach each engagement comes from a set of views about what makes technical change useful — and what makes it harmful. These are described here plainly.
Back to homeWhere our approach comes from
Marsh Crest Field started from a straightforward observation: most AI adoption in business is driven by what tools can do in general, not by what a specific organisation actually needs.
A customer service team with three recurring enquiry types and two that require human judgement does not need the same system as one with forty enquiry types and consistent phrasing. But both might buy the same product.
Our work begins with looking at what already exists — real records, real processes, real staff — before considering what to change. That habit shapes everything: how we scope, how we build, how we document, and what we consider a good result.
It also means we sometimes conclude that a process does not suit automation at all. That conclusion is a legitimate outcome of an engagement, not a failure of it.
What we think good AI integration looks like
Narrow scope, clear boundaries
We believe AI works best in business when it is applied to a narrow, well-understood part of a process — not deployed across everything at once. Narrow scope makes it easier to evaluate, easier to explain to staff, and easier to withdraw if it does not work as expected.
The vision is not a transformed business. The vision is a specific task that takes less time, with the same quality, and with documentation of what changed.
Honesty about limits
Every AI system has tasks it handles poorly. We document those as part of the deliverable. An organisation that knows what its system cannot do is in a better position than one that assumes it can do everything.
What we hold to be true
Observation precedes recommendation
We do not arrive with a preferred solution. We look at what an organisation actually does, what its records contain, and what its staff find difficult. The recommendation follows from that.
A "do not automate" finding has value
When analysis shows that a process relies on context, relationship, or judgement that a system cannot replicate, that is a useful conclusion — not a wasted engagement.
What changes must be named
If a deployment removes a step from a process, that step should be identified and the reason for removing it documented. Nothing should disappear without a record.
Withdrawal is part of the design
A good deployment can be stopped. We include withdrawal documentation in every engagement so the client is never dependent on us to undo what we did.
Staff understanding matters as much as the system
A system that works but that staff distrust or misuse does not deliver the intended result. We train the people who use the system, not just the people who approved it.
Fixed scope protects both sides
An open-ended engagement can expand indefinitely. A defined scope gives the client a clear endpoint and gives us clear accountability. We prefer that structure.
How beliefs translate into work
These are not aspirations. They are decisions we have built into the structure of each engagement.
Every engagement begins with source review — actual records, not assumed patterns. The scope is written after this review, not before.
The customer service assessment engagement explicitly includes the option to recommend no change. The fee is the same either way.
The layer diagram we produce for each service shows the existing process as the base layer and names anything that is removed or changed.
Withdrawal documentation is a standard deliverable. You receive it at handover, not only if you ask for it.
Staff who will use the system are involved in building the evaluation set — their questions shape how the system is tested before it goes live.
All three services have fixed timelines — four, six, or seven weeks — and fixed fees. There is no mechanism for automatic extension.
The people inside the process
Every process we work on has people in it. Customers waiting for a response. Staff searching through manuals. Editors reviewing a draft before it goes out. The quality of their experience matters.
We pay attention to where in the process human judgement is essential — and we mark those points clearly in the layer diagram. Automation is placed around them, not over them.
The customer who needs a response that a form answer cannot provide should still reach a person. The staff member who cannot find a procedure in the new search system should have an obvious fallback. The editor who disagrees with an automated draft should have a written category list that gives them standing to override it.
These are design requirements, not afterthoughts.
Change for a reason, not for novelty
AI is not inherently an improvement. The question is whether a specific application of it improves a specific thing. That question can only be answered by looking at the specific thing.
We do not introduce new approaches because they are current. We introduce them when analysis suggests they address something the existing process handles poorly.
What this means in practice
We apply the same methods regardless of which AI tools are currently prominent. The analysis determines the tool, not the other way around.
If a process already works, we say so. Continuity is not a failure. A finding that confirms the existing approach has value.
Where we do introduce something new, we include quality sampling so you know within a month whether it is performing as intended.
What we are open about
What we include in documentation
The findings, the configuration decisions, the question types the system does not handle well, and the procedure for withdrawal. Not just the parts that reflect well.
What we charge
Fixed fees, stated at the start: ¥30,000–¥41,000 depending on service. No variable billing. No additional costs unless agreed in writing beforehand.
What we do not do
We do not claim outcomes in advance. We do not produce projections that assume adoption rates we have not measured. We describe what the work produces, not what it might produce.
How we work alongside your team
The engagement involves your staff — not just at the end, but during the source review, the scope development, and the evaluation. Their knowledge of the process is not something we replicate from outside; it informs the work throughout.
We are not embedded in the organisation long-term. But during the engagement, we rely on the people who know the process, and the final documentation reflects what they contributed.
Who is involved and when
Source review
We ask for access to existing records and often speak with the people who work with them day-to-day.
Evaluation set
The questions used to test the system are built with input from staff who actually use the process — not generated by us independently.
Handover
Training happens with the people who will use the system, and the documentation is written to be useful to someone who was not part of the engagement.
What happens after the engagement
An engagement with us ends with documentation you keep. That includes the findings, the system configuration, the question types it handles poorly, and the withdrawal procedure.
If a staff member leaves and someone new needs to understand what is running, the documentation should be sufficient for that. If the organisation decides to stop using the system, the withdrawal procedure is written and does not require us to be involved.
We do not offer ongoing retainers or subscription support. This is a design choice: it encourages us to make the initial work good enough to stand on its own.
If further work is needed later — a new scope, a different process — that would be a new engagement with the same structure. It would not assume familiarity with the earlier work.
What to expect from an engagement
You will know what we found
The findings are documented in full, including findings that do not support automation. You receive the analysis, not just the recommendation.
You will know what the system does not do
The written deliverable includes a note on question types or situations the system handles poorly. This is a standard part of the handover, not optional.
You will not be surprised by costs
The fee is stated at the beginning. The work is scoped before it begins. There is no mechanism for the engagement to expand without a new agreement.
You will be able to stop
Withdrawal documentation is included at handover. If you decide the system is not working as intended, you have what you need to discontinue it without involving us.
If this approach matches what you are looking for
Describe the process you have in mind and we will consider whether we can be useful. There is no commitment involved in the first conversation.
Get in touch