The process runs on paper, a WhatsApp group and one spreadsheet. Digitised without making the fast path slower.
This is the process and its adoption, not the application build. We map what people actually do against what the SOP says, and the gap is usually the project. Approvals get an audit trail, capture works on a phone with no signal, and the fast path stays fast, because a system slower than the paper it replaced gets worked around.
- Companies delivered for
- 20+
- Median to first production-grade artefact
- 6 weeks
- Software a real user can open
- By week 3
- Team on a build
- Pod of three
- Published case study for this pillar
- None yet
Five ways a process tells you it has left the system
Nobody books a call about digitisation. They book a call about one of these, after it has already cost them something.
The record exists, in a photo in a WhatsApp group
Somebody photographed the signed docket and posted it to the group, so the work is proved. Finding it again months later means scrolling back through a chat full of other photographs, and the person who posted it has left.
The spreadsheet has one owner and no history
It is the real system of record and everybody knows it. There is no version history worth the name and no record of who changed a cell, so when the owner is on leave the process runs on guesswork.
A compliance request means a week of reconstructing what happened
The answer gets assembled from email, a chat thread and somebody's memory of a phone call. It is usually correct. It is never quick, and it is never assembled the same way twice.
The last system was slower than paper, so the floor went back to paper
Now you have both. The system is updated from the paper at the end of the shift, which means the screen is always behind the yard, and the people who have to reconcile them trust neither.
Nobody can say how long a step takes
Not because it is hard to measure, but because it was never recorded. Every conversation about capacity is a conversation about opinions, and the most senior opinion wins.
What we have actually delivered
We have not published a named process digitisation case yet, so these are firm-wide delivery figures. We will say on the call which of them came from work that looked like yours.
From the sentence on the first call to the part of the work it becomes
The complaint arrives as an operations problem with a date attached. Each one belongs to a different part of this job, and they need doing in a particular order.
- The record is a photo in a WhatsApp groupCapture at the point of work
- The spreadsheet has one owner and no historyOne system of record, with history
- A compliance request takes a week to answerApprovals and the audit trail
- The floor went back to paperThe fast path, and adoption
- Nobody can say how long a step takesTiming the steps
The work, in the order it has to happen
The sequence matters more than the tooling. Skipping the first box is how a project ends up faithfully automating a process nobody follows.
- 01
Watch the process being done
Not a workshop with a whiteboard. Somebody stands where the work happens and follows a real job from the first form to the record it ends up in, including the parts the SOP does not mention because they were invented to get around it.
- 02
Write down both processes
The one in the document and the one people follow. The gap between them is the project. Some of that gap is drift worth removing and some of it is the reason the operation works at all, and telling those apart is the whole skill.
- 03
Decide what should not be digitised
Every step gets one of three decisions: onto the system, assisted by it, or deliberately left alone. The steps that stay manual are named and written down, so nobody adds them back in month four believing it was an oversight.
- 04
Put capture where the work happens
On a phone, in a hand, offline, with the fewest taps we can get the common case down to. If recording the job takes longer than doing the job, the record will be invented at the end of the shift and you will have paid for worse data.
- 05
Move the process across in front of people
The new path runs alongside the old one on real work, with the supervisor watching. The old path is retired when the people using it agree it can be, not on the date in the plan.
The process in the SOP, and the process people follow
Digitising the documented process gets you a system nobody uses. The rows worth arguing about are the ones where the two sides do not match.
- Inspector records the batch in the systemPhotographed, posted to the group
- Supervisor signs the docket at handoverSigned on Friday, in a batch, from memory
- Discrepancy raised as a casePhone call, then a line in the sheet
- Quality hold released by the quality leadReleased verbally, recorded next morning
- Daily count filed before the shift endsFiled the following day, off the paper
- Weekly exception report circulatedNobody has produced it in a year
What the trail has to answer before we call it digitised
A record that cannot answer these will be reconstructed by hand the next time somebody asks, which is the situation you are paying to leave.
Who did it, and who approved it
Named people, not a shared login on the terminal by the door. A shared login means the trail says the warehouse did it, which is not an answer an auditor can work with.
When, in the order it actually happened
Timestamps taken at the point of capture, so a record made at the bench and a record typed up at the end of the shift can be told apart rather than both reading as six o'clock.
What it looked like before it was changed
Amendments are kept as amendments, with the previous value and the reason. Overwriting a field destroys the only evidence that a decision was ever reconsidered.
The evidence attached to the record, not beside it
The photograph, the signature and the scanned docket held against the job they belong to, rather than in a shared folder organised by date that somebody has to search.
What the person was allowed to do at the time
Permissions change, people move roles. Being able to show what somebody was authorised to do on the day, not what their account can do today.
Exported by your team, without ringing us
Your people produce the pack for an auditor from the system itself. If answering a compliance request still needs a developer, nothing has actually improved.
Capture designed for an aisle, not a desk
The person recording the work is standing up, holding something, and possibly wearing gloves. Every decision below follows from that rather than from what looks good in a demo.
The signal drops, the work does not stop
The record is written on the device and syncs when there is coverage. No signal is ordinary in a cold store, a basement or a site with one bar, and designing for it as the exception is how a shift of jobs goes missing.
Two devices, one job, no silent overwrite
When the same job is edited in two places the system says so and shows both versions, rather than quietly keeping whichever synced last. Silent last-write-wins is how offline capture loses a day of counts without anyone noticing.
Counted, because it decides adoption
The number of taps to record the common case is a design target we set at the start and hold ourselves to, not something discovered after launch. The rare case is allowed to be slower, and usually should be.
Scan, photograph, pick from a list, and only then type
A barcode beats a list and a list beats a keyboard, especially with gloves on. Free text stays where judgement genuinely belongs, because free text is where the reporting you wanted goes to die.
Start with the phone that is already in the building
Ruggedised hardware is sometimes right and often a way of postponing the project. We start on what people already carry and specify hardware once the work has proved it is needed.
Three honest destinations for a step
Not every step belongs on the system, and saying which ones do not is part of this work rather than a caveat at the end of it.
- On the system
The step that is a written rule with a record attached
Fixed thresholds, allocations by a stated rule, the same check made the same way every time. These belong on the system because software follows a written rule exactly, on every job, and leaves a record without being asked to.
- Assisted
The step where a person decides and the system remembers
The system shows what is known, the person makes the call, and the reason is captured in the same action rather than in a separate form afterwards. Judgement on the floor belongs here, and forcing it up a tier is what makes people distrust the whole thing.
- Left alone
The step that is a conversation and should stay one
The handover at shift change, the walk along the line, the call to a supplier who is also a neighbour. Putting a form in front of these does not record them, it adds a form and loses the conversation.
Rolling it out so the floor does not quietly go back to paper
This is where these projects actually die, and they die quietly. Nobody announces that they have stopped using the system.
- 01
Start with the shift that hates the current process most
Not the most compliant team, and not the most senior. The team carrying the worst workaround has the strongest reason to make the new path work, and they will tell you plainly and early when it does not.
- 02
Run both paths on the same real work
For an agreed period the job is recorded both ways and the two records are compared. That comparison is what proves the new path is complete, and it convinces a supervisor in a way that no amount of training will.
- 03
Time the common case on the floor, with a stopwatch
If the new path is slower than the paper it replaces, we fix that before rolling any further. A system that costs an operator time on every job gets worked around whatever the policy says, and nobody announces the workaround.
- 04
Train the person the others copy
Every shift has one and it is rarely the supervisor. Once that person uses the system without complaining about it, the rest of the shift follows without being asked to.
- 05
Take the paper away on a date people agree to
Leaving the paper path available as a fallback means the paper stays the real path. It gets removed deliberately, once both paths have been compared and the gaps closed, rather than on the go-live date in the plan.
- 06
Watch the fallbacks once the paper has gone
Every workaround is a design note. Reverting to the sheet, the photograph or the phone call gets recorded, and the ones that keep recurring go back into the build instead of into a reminder about policy.
What the first six weeks look like on a process
Three phases, the same as every engagement here. What differs on this kind of work is what has to be true by week three.
- Week 1
The audit, fixed fee
Two calls, and one real job followed from the first form to the record it ends up in. You get a one-pager naming the gap between the documented process and the one people follow, what that gap is costing you, and the order to close it in. Yours whether or not we go further.
- Week 2
The first slice is chosen
A pod of three starts on one process end to end, usually the one carrying the worst workaround rather than the one that demonstrates best. The demo-friendly screen teaches you nothing about whether anybody will use it at six in the morning.
- Week 3
It is in somebody's hands
Software a real user can open, on a real device, with real jobs in it. This is the week you discover that the step you were told is optional is not optional, which is exactly why it is not week eight.
- Weeks 4 to 6
Both paths run, then one is retired
The new path runs alongside the paper on real work and the two are compared before anything is switched off. Across our engagements the median time to a first production-grade artefact is six weeks.
- Week 7 onwards
Operate
Quarterly reviews and on-call governance. On this kind of work the reviews are mostly about workarounds: what people have started doing around the system, and what each one says about a step we got wrong.
There is no client name on this page
Worth explaining rather than papering over, because you will notice it anyway.
What we can say
Woodfrog has been going since 2023, from Pune, delivering across India, APAC and the US, for 20+ companies and 50+ projects. The median time to a first production-grade artefact is six weeks, and software a real user can open arrives by week three.
Those are firm-wide delivery figures. None of them is a process digitisation result, and we are not going to present them as one.
What we will not do
Our published case studies come from analytics, AI and AI governance. The recovery and margin figures on those pages belong to the engagements that produced them, and they stay there. A number from a different discipline would tell you nothing about whether your inspectors will use the thing, so it is not on this page.
What to ask instead
Ask which of your steps we would refuse to digitise, and why. Ask what we would do about the supervisor who signs a week of dockets on a Friday afternoon. Ask how we would know, six months after go-live, whether the floor is still using it. Then judge us on the one-pager from week one, which you keep either way.
When there is one
A named process digitisation case will appear here once a customer agrees to be named and the numbers have been through their own finance function. That is the bar we hold every number on this site to.
Questions operations and compliance leads ask us
The ones that come up on almost every first call about this work.
We tried this before and the floor went back to paper. Why would this go differently?
Because the thing that killed it is measurable, and it usually goes unmeasured. We time the common case on the floor against the paper it replaces, run both paths side by side on real work, remove the paper on a date people have agreed to, and then count the fallbacks afterwards. If the new path is slower, that is a defect and we treat it as one.
Do we have to fix the process before we digitise it?
You have to decide what it is, which is not the same as fixing it. A good deal of the fixing happens as a side effect of writing both versions down, because a lot of drift is a workaround for something nobody owns any more. Waiting until the process is tidy is how organisations stay on paper indefinitely.
Our SOP is years out of date. Is that a problem?
It is the normal state and it is genuinely useful, because the gap between the SOP and the floor is the map of everything the operation had to invent to keep working. We do not start by correcting the document. We start by recording what people actually do, then decide document by document which version should win.
The people who do this work are not at a desk, and some of them will not use a phone.
That is a design constraint from day one rather than a training problem to solve later. Capture is built offline first, on the device people already carry, with the common case reduced to as few taps as we can manage. Where a person genuinely should not be holding a phone, the step is captured by somebody who is, or it stays manual and we say so.
Several of our sites have no reliable signal.
The record is written on the device and syncs when coverage returns, and the test we hold ourselves to is that somebody can finish a job with no signal and have it recorded correctly once they are back in coverage. Conflicts between two devices are shown rather than resolved silently, because a silent overwrite loses a shift of counts without anyone noticing.
Will this hold up in an audit?
We build the trail to answer the questions an auditor actually asks: who did it, who approved it, when, what it looked like before it was changed, what that person was authorised to do at the time, and where the evidence is attached. Whether that meets the standard you are held to is a call for your compliance people, and we build to what they tell us rather than to what we assume.
How is this different from your applications and automation page?
That page is about building or replacing the system itself. This one is about the process that will run on it and whether people will actually use it, which is a different job with a different way of failing. A well-built application on top of a process nobody mapped is the most expensive way to keep the spreadsheet.
What if some steps should stay manual?
Several of them should, and we name them. A step that is really a conversation, or a low-volume check that is somebody's only regular look at the process, usually loses more than it gains when a form is put in front of it. Those decisions are written down with the person who agreed to them, so they are not quietly reversed later.
Once it is live, who owns the process definition?
Your people do. Each step carries its decision, on the system, assisted, or left alone, written down with the name of the person who agreed to it, so a change later is something somebody decides rather than something that drifts. The software follows the same rule: you own it from the first commit, in your repositories, handed over documented with a runbook, and the test we hold ourselves to is whether your team can change a step without us in the room.
What if week one says we should not do this?
Then that is what the one-pager says, and you keep it. Sometimes the honest answer is that the process needs an owner rather than a system, or that one manual step is the entire problem. We would rather write that down in week one than build something you stop using in month six.
The rest of the practice
These are genuinely different jobs with different ways of failing. Most engagements start in one of them.
- Data engineeringJobs that finish, migrations that reconcile, and storage that stops paying for cold data.
- Data integration and governanceOne set of records the finance team and the operations team both accept.
- Data platforms and modernisationOff the platform you outgrew, without a twelve-month freeze on new reporting.
- Apache SupersetSuperset built and run by people who commit to the project, including embedding and Kubernetes.
- Command centresThe one screen an operations floor runs the day from, not another dashboard.
- AI evaluationA graded eval set, because an AI system cannot simply pass or fail a test suite.
- AI governanceGovernance you can defend in a board meeting and audit on demand.
- AI agentsOne reasoning agent on Claude, on your live data, with evidence and a kill switch.
- Data agentsAgents that watch the data, flag what moved, and explain what is driving it.
- AI use case, guaranteedOne production agent in eight weeks, or you do not pay for the build.
- Applications and automationThe system your team works in all day, built or replaced in slices.
- Application modernisationThe system nobody wants to touch, replaced a slice at a time rather than rewritten.
- System integrationSystems that stop disagreeing about the same customer, order and item.
Start with the Week 1 audit
Two calls, a fixed fee, and one real job followed from the first form to the record it ends up in. You get a one-pager naming the gap between the process you documented and the process people follow, what that gap is costing you and the order to close it in. Yours whether or not we build anything. NDA-friendly, fixed scope. hello@woodfrog.tech, Pune.