From Excel sheets to a closed-loop audit system.
Rebuilding how a contract manufacturing operation prepares, runs, and resolves supplier audits.
Building for reality, not just the canvas.
© 2026 Designed & Documented by Akash Mounabhargav. All Rights Reserved.
From Excel sheets to a closed-loop audit system.
Rebuilding how a contract manufacturing operation prepares, runs, and resolves supplier audits.
Project Overview
In the contract manufacturing sector, supplier quality assurance is crippled by legacy, paper-based processes. Highly skilled auditors were wasting up to 40% of their time acting as data-entry clerks, chasing emails and formatting reports. Without standardized data sets, tracking historical performance was impossible, and resolving non-conformances (NCs) became a black hole of untracked communication with zero verification.
My role as PRODUCT DESIGNER
I led the end-to-end product design of a centralized platform that fundamentally re-engineered the client-supplier workflow into a verifiable, closed-loop system.
Modular Master Templates: Architected a scalable form-building engine where complex, section-based audits are built once and deployed everywhere. Integrated an AI-driven option generator to eradicate setup friction.
Reality-Anchored Execution: Optimized the field interface specifically for shop-floor tablets. Integrated automated real-time scoring to remove human bias , alongside rich contextual text observations and instant photo validation.
Accountability Architecture: Replaced email-based tracking with a unified dashboard. The system automatically flags NCs, enabling clients to define corrective actions and suppliers to upload resolution proof within a single, immutable environment.
Building for reality, not just the canvas.
© 2026 Designed & Documented by Akash Mounabhargav. All Rights Reserved.
More Case Studies.
More Case Studies.
More Case Studies.
Transforming university campus mobility
Project ELEVAC.
Role
Product Designer. Led research and design end to end.
Company
Custiv, B2B SaaS for contract manufacturing.
Team
Me (design), engineering team, audit and sourcing teams
as domain partners.
Scope
Form architecture, audit execution, scoring logic, evidence capture, non-conformance workflow, supplier-side experience, role-based access.
Shipped
Live product. Form builder, audit execution on tablet and desktop, automated scoring, NC resolution loop, AI form generation in a later release.
CLIENT
CLIENT
SALES
SALES
SALES
SALES
ENGINEERING + QC
ENGINEERING + QC
SOURCING
SOURCING
AUDIT TEAM
AUDIT TEAM
OPERATIONS
OPERATIONS
PART
PART
DRAWINGS
DRAWINGS
RFQ
RFQ
& QUOTE
& QUOTE
NEGOTIATION
NEGOTIATION
MANUFACTURING
MANUFACTURING
PLAN
PLAN
SUPPLIER
SUPPLIER
SHORTLIST
SHORTLIST
SUPPLIER
SUPPLIER
AUDIT
AUDIT
PRODUCTION
PRODUCTION
The last gate before production is committed.
The last gate before production is committed.
AUDIT TEAM
AUDIT TEAM
SUPPLIER
SUPPLIER
AUDIT COMPLETED
AUDIT COMPLETED
FINDINGS DERIVED
FINDINGS DERIVED
AUTOMATICALLY
AUTOMATICALLY
RECOMMENDATION
RECOMMENDATION
+ TARGET DATE
+ TARGET DATE
AUDITOR
AUDITOR
RE-ASSESSES
RE-ASSESSES
RESOLVED
RESOLVED
CORRECTIVE ACTION
CORRECTIVE ACTION
+ NAMED OWNER
+ NAMED OWNER
EVIDENCE
EVIDENCE
ATTACHED
ATTACHED
SHARE NON-CONFORMANCES
SHARE NON-CONFORMANCES
SUBMIT FOR REVIEW
SUBMIT FOR REVIEW
RESOLUTION IMPROVES THE ORIGINAL AUDIT SCORE
RESOLUTION IMPROVES THE ORIGINAL AUDIT SCORE
1
Create. Build reusable form templates and define the evaluation logic once.
2
Conduct. Run the audit against those forms, capturing responses, remarks and proof in context.
3
Resolve. Derive non-conformances (NCs) automatically and give the supplier a structured way to respond.
4
Improve. Verify corrective actions, resolve findings, and reflect genuine improvement in the audit record.
THE SHORT VERSION.
A supplier audit decides whether a factory is allowed to build a client's parts. At Custiv, that decision ran on Excel sheets that were duplicated per supplier, printed, carried to the factory, filled in by hand, and scored manually afterwards. The problems found during the audit then left the system entirely and lived in email until someone remembered to follow up.
I spent the first months of this project mapping how a manufacturing project actually moves through the company, then went into the field with auditors. The research changed the brief. We had been asked to digitise a form. What the operation needed was a system that could hold an audit from the moment someone writes the first question to the moment the supplier's last defect is verified as fixed.
I designed that system: a reusable form architecture, an execution surface built for a factory floor, scoring that the product computes instead of the auditor, automatic derivation of non-conformances from responses, and a supplier-facing workflow that closes the loop and updates the original audit record when problems are genuinely fixed.
THE SHORT VERSION.
A supplier audit decides whether a factory is allowed to build a client's parts. At Custiv, that decision ran on Excel sheets that were duplicated per supplier, printed, carried to the factory, filled in by hand, and scored manually afterwards. The problems found during the audit then left the system entirely and lived in email until someone remembered to follow up.
I spent the first months of this project mapping how a manufacturing project actually moves through the company, then went into the field with auditors. The research changed the brief. We had been asked to digitise a form. What the operation needed was a system that could hold an audit from the moment someone writes the first question to the moment the supplier's last defect is verified as fixed.
I designed that system: a reusable form architecture, an execution surface built for a factory floor, scoring that the product computes instead of the auditor, automatic derivation of non-conformances from responses, and a supplier-facing workflow that closes the loop and updates the original audit record when problems are genuinely fixed.
BEFORE THE AUDIT, THERE IS A WHOLE COMPANY.
I joined the project with the tech team while Custiv was building a suite covering the full lifecycle of a contract manufacturing project. Before anyone could design a single screen, we had to know what that lifecycle actually was.
I spent the first few weeks in conversation with people across sales, quality control, sourcing and project management. Not asking what they wanted built. Asking what they do, what they own, what arrives on their desk and what they hand off.
The lifecycle we mapped:
BEFORE THE AUDIT, THERE IS A WHOLE COMPANY.
I joined the project with the tech team while Custiv was building a suite covering the full lifecycle of a contract manufacturing project. Before anyone could design a single screen, we had to know what that lifecycle actually was.
I spent the first few weeks in conversation with people across sales, quality control, sourcing and project management. Not asking what they wanted built. Asking what they do, what they own, what arrives on their desk and what they hand off.
The lifecycle we mapped:
The audit sits at a specific and consequential transition. Sourcing can propose a supplier. Only the audit determines whether that supplier can actually execute. A missed defect here surfaces later as scrapped parts, missed delivery dates, and a client relationship in trouble.
That framing mattered for everything after. We were not designing a form tool. We were designing the control point between "we think this factory can do it" and "we are committing production to this factory."
WE WATCHED AUDITS HAPPEN, BEFORE WE DESIGNED ANYTHING.
Here is how audits worked when I started.
Someone in the audit team built a form in Excel, occasionally using ChatGPT to sharpen question wording. The sheet was printed and physically carried to the supplier's facility. During the walkthrough, auditors wrote into blank remark cells: the document ID of a certificate they needed to verify later, observations that would later become formal findings, and notes to themselves about things worth remembering. Evidence was collected separately, as physical documents or photographs taken at whatever moment was convenient. Afterwards, all of it had to be interpreted, scored by hand, organised, and turned into findings that could be sent to the supplier.
I worked with the sourcing and audit teams to understand how forms were prepared, and observed the audit workflow in practice with auditors.
The questions I was trying to answer were about the work, not the interface:
What does an auditor actually look at on a factory floor?
What do they have to hold in their head between one question and the next?
Which questions can be settled by looking, and which require a document in hand?
When does evidence get collected, and does it stay attached to anything?
Which observations turn into formal findings later, and how does that decision get made?
What happens after the auditor leaves the building?
That last question turned out to be the one the existing process had no answer for.
FIVE STRUCTURAL FINDINGS.
The Excel file was the visible symptom. The research surfaced five problems underneath it.
WE WATCHED AUDITS HAPPEN, BEFORE WE DESIGNED ANYTHING.
Here is how audits worked when I started.
Someone in the audit team built a form in Excel, occasionally using ChatGPT to sharpen question wording. The sheet was printed and physically carried to the supplier's facility. During the walkthrough, auditors wrote into blank remark cells: the document ID of a certificate they needed to verify later, observations that would later become formal findings, and notes to themselves about things worth remembering. Evidence was collected separately, as physical documents or photographs taken at whatever moment was convenient. Afterwards, all of it had to be interpreted, scored by hand, organised, and turned into findings that could be sent to the supplier.
I worked with the sourcing and audit teams to understand how forms were prepared, and observed the audit workflow in practice with auditors.
The questions I was trying to answer were about the work, not the interface:
What does an auditor actually look at on a factory floor?
What do they have to hold in their head between one question and the next?
Which questions can be settled by looking, and which require a document in hand?
When does evidence get collected, and does it stay attached to anything?
Which observations turn into formal findings later, and how does that decision get made?
What happens after the auditor leaves the building?
That last question turned out to be the one the existing process had no answer for.
The same form was rebuilt for every supplier. Audit forms are organised by domain, not by vendor. A machining audit asks the same questions of every machining supplier. The questions are constant; only the answers vary. The team was duplicating identical sheets, which made cross-supplier comparison unreliable and made every review start from scratch.
Evidence lived outside the question it justified. An auditor would answer on paper, note a document number, photograph something, and deal with the actual proof separately. The answer and the thing that justified it were conceptually inseparable and operationally unconnected.
Scoring depended on whoever was running it. There was no standard scoring logic. The admin overseeing audits defined it, auditors calculated it by hand afterwards, and the team was running two or three different scoring formats across different audits with no clear reason. If that admin left, the methodology left with them. Two audits scored under different schemes cannot be compared, which quietly destroys the historical record.
A finished audit was a frozen snapshot. An audit could identify problems and produce a score. When the supplier then fixed those problems, nothing in the process could record it. The system remembered the failure and had no way to remember the recovery, or to measure how fast a supplier responded when told something was wrong.
The audit did not end when the audit ended. Findings still had to be communicated, corrected, verified and closed. The most important part of the process was the part with no system behind it at all.
That last finding reframed the project. An audit is a lifecycle that begins when someone writes the first question and ends when the last defect is verified fixed. The visit is one stage inside it.
FIVE STRUCTURAL FINDINGS.
The Excel file was the visible symptom. The research surfaced five problems underneath it.
The same form was rebuilt for every supplier. Audit forms are organised by domain, not by vendor. A machining audit asks the same questions of every machining supplier. The questions are constant; only the answers vary. The team was duplicating identical sheets, which made cross-supplier comparison unreliable and made every review start from scratch.
Evidence lived outside the question it justified. An auditor would answer on paper, note a document number, photograph something, and deal with the actual proof separately. The answer and the thing that justified it were conceptually inseparable and operationally unconnected.
Scoring depended on whoever was running it. There was no standard scoring logic. The admin overseeing audits defined it, auditors calculated it by hand afterwards, and the team was running two or three different scoring formats across different audits with no clear reason. If that admin left, the methodology left with them. Two audits scored under different schemes cannot be compared, which quietly destroys the historical record.
A finished audit was a frozen snapshot. An audit could identify problems and produce a score. When the supplier then fixed those problems, nothing in the process could record it. The system remembered the failure and had no way to remember the recovery, or to measure how fast a supplier responded when told something was wrong.
The audit did not end when the audit ended. Findings still had to be communicated, corrected, verified and closed. The most important part of the process was the part with no system behind it at all.
That last finding reframed the project. An audit is a lifecycle that begins when someone writes the first question and ends when the last defect is verified fixed. The visit is one stage inside it.
FOUR STAGES, ONE SYSTEM.
The product direction moved from "digitise the audit form" to "hold the entire audit lifecycle in one place." Four connected stages:
Everything above is a decision inside one of those stages, and the constraint that forced it.
FOUR STAGES, ONE SYSTEM.
The product direction moved from "digitise the audit form" to "hold the entire audit lifecycle in one place." Four connected stages:
Everything above is a decision inside one of those stages, and the constraint that forced it.
FAMILIAR ENOUGH TO ADOPT, STANDARD ENOUGH TO SELL.
The first real tension was not technical.
Custiv's audit team already understood their forms and their vocabulary. Rebuilding that mental model from scratch would have meant asking experienced auditors to relearn their own job, which is the fastest way to have a tool rejected. At the same time, this was being built as a SaaS product for other organisations, so it could not be a bespoke replica of one company's spreadsheet habits.
We had to build something familiar enough that Custiv's team would adopt it, and generic enough that another manufacturer could pick it up without modification.
The resolution was the master form template. Teams build a form once and reuse it across every audit in that domain. A form has a name, a domain, an optional set of applicable industries that helps match it to the right supplier type, and any number of sections, each holding any number of questions. Forms are tagged and filterable so a team of any size can find the right one.
Role-based access sits on top of this. Editing an evaluation framework is a different kind of act from filling one in, and the people who should be able to do each are different. Permissions were designed around that distinction rather than around job titles.
The point of this architecture was not to make forms more powerful. It was to make the evaluation framework stable enough that two audits, run by two different people, six months apart, remain comparable.
FAMILIAR ENOUGH TO ADOPT, STANDARD ENOUGH TO SELL.
The first real tension was not technical.
Custiv's audit team already understood their forms and their vocabulary. Rebuilding that mental model from scratch would have meant asking experienced auditors to relearn their own job, which is the fastest way to have a tool rejected. At the same time, this was being built as a SaaS product for other organisations, so it could not be a bespoke replica of one company's spreadsheet habits.
We had to build something familiar enough that Custiv's team would adopt it, and generic enough that another manufacturer could pick it up without modification.
The resolution was the master form template. Teams build a form once and reuse it across every audit in that domain. A form has a name, a domain, an optional set of applicable industries that helps match it to the right supplier type, and any number of sections, each holding any number of questions. Forms are tagged and filterable so a team of any size can find the right one.
Role-based access sits on top of this. Editing an evaluation framework is a different kind of act from filling one in, and the people who should be able to do each are different. Permissions were designed around that distinction rather than around job titles.
The point of this architecture was not to make forms more powerful. It was to make the evaluation framework stable enough that two audits, run by two different people, six months apart, remain comparable.
THE QUESTION IS THE UNIT OF DESIGN.
Most of the product's intelligence sits inside a single question object. Designing it well meant every downstream stage got easier.
Each question carries:
A title and an optional description explaining what the question is actually assessing, so a newer auditor is not guessing at intent.
A response type. Multiple choice, or yes/no.
Four response options, written as descriptions of real supplier behaviour. Not "Exceeds Expectations" but "Formal supplier qualification, audits, and periodic performance reviews are conducted and documented." Not "Unacceptable" but "No supplier evaluation or approval process in place." Scores of 3, 2, 1 and 0 sit behind those sentences.
An importance level. High, Medium or Low, so a routine confirmation and a critical safety requirement are not visually identical on a factory floor.
Named proof requirements. The person building the form specifies exactly which documents justify an answer, as named requirements attached to the question. The auditor arrives knowing what to ask for.
A classification tag. Document Review or Visual Check, among others, so the auditor knows before reading the question whether this needs a certificate in hand or an observation.
THE QUESTION IS THE UNIT OF DESIGN.
Most of the product's intelligence sits inside a single question object. Designing it well meant every downstream stage got easier.
Each question carries:
A title and an optional description explaining what the question is actually assessing, so a newer auditor is not guessing at intent.
A response type. Multiple choice, or yes/no.
Four response options, written as descriptions of real supplier behaviour. Not "Exceeds Expectations" but "Formal supplier qualification, audits, and periodic performance reviews are conducted and documented." Not "Unacceptable" but "No supplier evaluation or approval process in place." Scores of 3, 2, 1 and 0 sit behind those sentences.
An importance level. High, Medium or Low, so a routine confirmation and a critical safety requirement are not visually identical on a factory floor.
Named proof requirements. The person building the form specifies exactly which documents justify an answer, as named requirements attached to the question. The auditor arrives knowing what to ask for.
A classification tag. Document Review or Visual Check, among others, so the auditor knows before reading the question whether this needs a certificate in hand or an observation.
Writing the options as behavioural descriptions is the decision I would defend hardest. The old process asked auditors to convert what they observed into a grade, and the conversion rate varied by person. The new one asks them to match what they observed to a written description of it. Consistency stops depending on the individual and starts being a property of how the question was written.
Writing the options as behavioural descriptions is the decision I would defend hardest. The old process asked auditors to convert what they observed into a grade, and the conversion rate varied by person. The new one asks them to match what they observed to a written description of it. Consistency stops depending on the individual and starts being a property of how the question was written.
Not every question needs proof. Some are settled by looking at a machine. The form builder makes that an explicit choice at design time rather than an on-the-spot judgement by whoever happens to be holding the tablet.
Not every question needs proof. Some are settled by looking at a machine. The form builder makes that an explicit choice at design time rather than an on-the-spot judgement by whoever happens to be holding the tablet.
SCORING BECAME PRODUCT LOGIC.
Response options carry fixed weights: 3, 2, 1, 0. Yes/no questions use their own defined weighting.
Each form produces a score out of 10. An audit's final score is the mean of the scores of the forms included in it.
The research turned up a case that a naive scoring model would have broken. Not every form is meant to be scored. Some exist to capture routine confirmations, like whether operators have received basic training, which the team confirms with the supplier but does not weigh against performance. Averaging those into the result would have distorted every score in the system.
So scoring is configurable per form, per audit. A Calculate Score toggle sits on each form inside an audit. Switched off, that form is excluded from the calculation entirely and displays no score, while its responses stay fully accessible. Switched on, it contributes.
WHAT THE AUDITOR SELECTS ON THE FLOOR
WHAT THE AUDITOR SELECTS ON THE FLOOR
POINTS
POINTS
WHAT THE SYSTEM DERIVES ON COMPLETION
WHAT THE SYSTEM DERIVES ON COMPLETION
Formal supplier qualification, audits, and periodic performance reviews are conducted and documented
Formal supplier qualification, audits, and periodic performance reviews are conducted and documented
3
3
NO FINDING
NO FINDING
Basic supplier evaluation criteria exist and are followed during onboarding
Basic supplier evaluation criteria exist and are followed during onboarding
2
2
OBSERVATION
OBSERVATION
Supplier selection is informal with limited documentation or evaluation depth
Supplier selection is informal with limited documentation or evaluation depth
1
1
MINOR NON-CONFORMANCE
MINOR NON-CONFORMANCE
No supplier evaluation or approval process in place
No supplier evaluation or approval process in place
0
0
MAJOR NON-CONFORMANCE
MAJOR NON-CONFORMANCE
No auditor converts judgement into a number. Consistency becomes a property of how the question was written.
No auditor converts judgement into a number. Consistency becomes a property of how the question was written.
AND HOW THE AUDIT SCORE IS CALCULATED
AND HOW THE AUDIT SCORE IS CALCULATED
Supplier Quality Mgmt
Supplier Quality Mgmt
CALCULATE SCORE · OFF
CALCULATE SCORE · OFF
—
—
Supply Chain Operations
Supply Chain Operations
CALCULATE SCORE · ON
CALCULATE SCORE · ON
4.6 / 10
4.6 / 10
=
=
FINAL AUDIT SCORE
FINAL AUDIT SCORE
4.59 / 10
4.59 / 10
Forms switched off are excluded
Forms switched off are excluded
from the calculation entirely,
from the calculation entirely,
never counted as a zero.
never counted as a zero.
The auditor no longer holds the methodology in their head or reaches for a calculator. The system holds the methodology, and it holds the same one for every audit and every auditor.
The auditor no longer holds the methodology in their head or reaches for a calculator. The system holds the methodology, and it holds the same one for every audit and every auditor.
BUILT FOR A FACTORY FLOOR, AND LOCKED TO IT.
An audit event is created by selecting the supplier, the facility, the date, the auditors, the supplier-side participants, and the forms to be used. There is no limit on forms per audit.
During the audit, the auditor moves through sections and questions on a laptop or tablet. Each question shows its description, its options, its proof requirements and a remarks field. Proof is attached directly to the question it justifies, photographed on the spot or uploaded as a PDF or spreadsheet. Remarks can be written by hand with a stylus on tablet, preserving the fast margin-note habit auditors already had on paper, except now the note is attached to a specific question in a system instead of a cell on a sheet that gets filed away.
BUILT FOR A FACTORY FLOOR, AND LOCKED TO IT.
An audit event is created by selecting the supplier, the facility, the date, the auditors, the supplier-side participants, and the forms to be used. There is no limit on forms per audit.
During the audit, the auditor moves through sections and questions on a laptop or tablet. Each question shows its description, its options, its proof requirements and a remarks field. Proof is attached directly to the question it justifies, photographed on the spot or uploaded as a PDF or spreadsheet. Remarks can be written by hand with a stylus on tablet, preserving the fast margin-note habit auditors already had on paper, except now the note is attached to a specific question in a system instead of a cell on a sheet that gets filed away.
Progress and scores save automatically, and the score updates as the audit proceeds. Each form shows its own completion state and running score.
Then the constraint that I think matters most. Once an audit has been conducted, desktop access to it is view-only. All edits have to be made on the tablet used during the audit.
This is deliberately inconvenient. An audit record is evidence about another company's operations, used to decide whether they get production work. Making it easy to revise that record later, from a desk, after conversations have happened, would undermine the entire purpose of conducting the audit in the first place. The product treats the moment of observation as the only valid moment of entry. Everything after that is review.
Progress and scores save automatically, and the score updates as the audit proceeds. Each form shows its own completion state and running score.
Then the constraint that I think matters most. Once an audit has been conducted, desktop access to it is view-only. All edits have to be made on the tablet used during the audit.
This is deliberately inconvenient. An audit record is evidence about another company's operations, used to decide whether they get production work. Making it easy to revise that record later, from a desk, after conversations have happened, would undermine the entire purpose of conducting the audit in the first place. The product treats the moment of observation as the only valid moment of entry. Everything after that is review.
NON-CONFORMANCES DERIVE THEMSELVES.
This is the point where the product stops being a form-filling application.
When an audit is marked complete, the system interprets every response against a fixed mapping:
0 points
Major non-conformance
1 point
Minor non-conformance
2 points
Observation
3 POINTS
No finding
NON-CONFORMANCES DERIVE THEMSELVES.
This is the point where the product stops being a form-filling application.
When an audit is marked complete, the system interprets every response against a fixed mapping:
The auditor no longer reads back through a completed audit hunting for problems. The findings are already sorted into Major, Minor and Resolved views by the time the audit closes, with counts visible at a glance.
Each finding carries its full context with it: the original question, the description of what it assessed, the response that was selected, whether proof was required, the proof that was attached, and the auditor's remarks. A finding is never an orphaned ticket that someone has to reconstruct the meaning of.
The auditor then adds a specific recommendation for each finding and sets a target resolution date for the audit, and shares the findings with the supplier.
The auditor no longer reads back through a completed audit hunting for problems. The findings are already sorted into Major, Minor and Resolved views by the time the audit closes, with counts visible at a glance.
Each finding carries its full context with it: the original question, the description of what it assessed, the response that was selected, whether proof was required, the proof that was attached, and the auditor's remarks. A finding is never an orphaned ticket that someone has to reconstruct the meaning of.
The auditor then adds a specific recommendation for each finding and sets a target resolution date for the audit, and shares the findings with the supplier.
The audit result stops being a document and becomes a work queue with owners and a deadline.
The audit result stops being a document and becomes a work queue with owners and a deadline.
THE SUPPLIER GETS A WORKFLOW, NOT A PDF.
The supplier does not need access to Custiv's internal audit system, and giving it to them would be wrong. They need the part that concerns them.
Sharing is two separate decisions. Share Non-Conformances sends the findings and recommendations. Share Audit Forms is a separate grant that lets the supplier see the underlying responses the auditor recorded. The default is that a supplier sees what they need to fix. Seeing how they were assessed is a deliberate act of disclosure by the auditor, not a side effect.
On their side, the supplier sees an Audit Report with the same score, finding counts and target date, and a primary action of Plan Corrective Actions. For each finding they can read the auditor's recommendation, write the corrective action they intend to take, assign a person in charge of it, set its implementation status, and attach proof that the fix happened.
THE SUPPLIER GETS A WORKFLOW, NOT A PDF.
The supplier does not need access to Custiv's internal audit system, and giving it to them would be wrong. They need the part that concerns them.
Sharing is two separate decisions. Share Non-Conformances sends the findings and recommendations. Share Audit Forms is a separate grant that lets the supplier see the underlying responses the auditor recorded. The default is that a supplier sees what they need to fix. Seeing how they were assessed is a deliberate act of disclosure by the auditor, not a side effect.
On their side, the supplier sees an Audit Report with the same score, finding counts and target date, and a primary action of Plan Corrective Actions. For each finding they can read the auditor's recommendation, write the corrective action they intend to take, assign a person in charge of it, set its implementation status, and attach proof that the fix happened.
Two things this design does that an email thread cannot. It puts a name against every corrective action, so accountability exists on the supplier's side too. And it keeps the client's recommendation and the supplier's response in the same object, so nobody has to reconstruct the conversation later.
Two things this design does that an email thread cannot. It puts a name against every corrective action, so accountability exists on the supplier's side too. And it keeps the client's recommendation and the supplier's response in the same object, so nobody has to reconstruct the conversation later.
RESOLUTION IS A RE-ASSESSMENT.
When the target date approaches, the auditor reviews the corrective actions.
Resolving a finding is not a status change. The auditor re-answers the original question. The Mark as Resolved action stays unavailable until the response moves to a passing value, which means a finding can only be closed out by re-assessing the thing that failed, against the same criteria, in the same system. There is a separate Close NC path for findings that will not be fixed, which keeps the record honest instead of forcing everything into a resolved state.
Resolving a finding improves the score of the original audit. This is the answer to the fourth research finding, the one about frozen snapshots. The audit record now holds both the initial state and the recovery, which means the system can represent a supplier getting better rather than preserving only the moment they failed.
RESOLUTION IS A RE-ASSESSMENT.
When the target date approaches, the auditor reviews the corrective actions.
Resolving a finding is not a status change. The auditor re-answers the original question. The Mark as Resolved action stays unavailable until the response moves to a passing value, which means a finding can only be closed out by re-assessing the thing that failed, against the same criteria, in the same system. There is a separate Close NC path for findings that will not be fixed, which keeps the record honest instead of forcing everything into a resolved state.
Resolving a finding improves the score of the original audit. This is the answer to the fourth research finding, the one about frozen snapshots. The audit record now holds both the initial state and the recovery, which means the system can represent a supplier getting better rather than preserving only the moment they failed.
AND THE PLATFORM WORKS IN BOTH DIRECTIONS.
Custiv audits its suppliers. Custiv's clients audit Custiv.
The workspace holds both: audits you conduct on your vendors, and audits scheduled for you by your clients, in one place, on the same form architecture. The supplier-side experience we built is not a bolt-on portal. It is the same system viewed from the other end of the relationship, which is what makes it credible as a product rather than as one company's internal tool.
AND THE PLATFORM WORKS IN BOTH DIRECTIONS.
Custiv audits its suppliers. Custiv's clients audit Custiv.
The workspace holds both: audits you conduct on your vendors, and audits scheduled for you by your clients, in one place, on the same form architecture. The supplier-side experience we built is not a bolt-on portal. It is the same system viewed from the other end of the relationship, which is what makes it credible as a product rather than as one company's internal tool.
WHAT ACTUALLY CHANGED.
Three things worth being precise about, including how much evidence sits behind each.
Audit execution: days to hours. During internal observational trials, the redesigned workflow reduced the time to conduct an audit from days to hours. Trial evidence was limited, so this is an observed internal result rather than a statistically validated benchmark. The direction was consistent across trials. The saving comes from removing repeated manual work across preparation, scoring, evidence handling and post-audit processing, not from any single feature.
Non-conformance resolution: weeks to 1–2 days. Project documentation records the expected resolution cycle moving from weeks to approximately one to two days, through direct collaboration between supplier and audit team in one system instead of over email.
Form creation: hours to minutes. A later release added AI-assisted form generation, where a user describes the audit in natural language and the system produces a structured form in the product's own format. The documented expectation was to compress an operation that took hours into minutes.
WHAT ACTUALLY CHANGED.
Three things worth being precise about, including how much evidence sits behind each.
Audit execution: days to hours. During internal observational trials, the redesigned workflow reduced the time to conduct an audit from days to hours. Trial evidence was limited, so this is an observed internal result rather than a statistically validated benchmark. The direction was consistent across trials. The saving comes from removing repeated manual work across preparation, scoring, evidence handling and post-audit processing, not from any single feature.
Non-conformance resolution: weeks to 1–2 days. Project documentation records the expected resolution cycle moving from weeks to approximately one to two days, through direct collaboration between supplier and audit team in one system instead of over email.
Form creation: hours to minutes. A later release added AI-assisted form generation, where a user describes the audit in natural language and the system produces a structured form in the product's own format. The documented expectation was to compress an operation that took hours into minutes.
Structural changes that are facts rather than measurements:
Manual score calculation was eliminated. Responses feed the scoring model directly.
Proof is captured at the question, at the moment of observation, from the device in the auditor’s hands.
Non-conformance identification is automatic and deterministic instead of a manual re-read of the completed audit.
A form that previously had to be duplicated per supplier became a reusable template, applied consistently across audits.
Supplier improvement became representable in the record for the first time.
Structural changes that are facts rather than measurements:
Manual score calculation was eliminated. Responses feed the scoring model directly.
Proof is captured at the question, at the moment of observation, from the device in the auditor's hands.
Non-conformance identification is automatic and deterministic instead of a manual re-read of the completed audit.
A form that previously had to be duplicated per supplier became a reusable template, applied consistently across audits.
Supplier improvement became representable in the record for the first time.
WHAT I WOULD DO DIFFERENTLY.
Three things I would push on with more time:
Historical comparison was the promise we did not fully deliver. Standardised scoring makes cross-supplier and over-time comparison possible for the first time. The product makes that data structurally available but does not yet surface it. The obvious next layer is supplier performance over time, and resolution speed as a supplier quality signal in its own right.
Offline behaviour deserved more of my attention. Factory floors have unreliable connectivity, and the product assumes a connection for autosave. I would want to know how the current design fails when the network drops mid-audit, and design that failure state explicitly rather than letting it be discovered.
The tablet-only edit constraint is right, and I would want to test its edges. It is the correct default. It also means a genuine transcription error found a week later has a more painful path to correction than it might need. I would want to design a visible, attributed amendment mechanism rather than relying on the constraint alone.
WHAT I WOULD DO DIFFERENTLY.
Three things I would push on with more time:
Historical comparison was the promise we did not fully deliver. Standardised scoring makes cross-supplier and over-time comparison possible for the first time. The product makes that data structurally available but does not yet surface it. The obvious next layer is supplier performance over time, and resolution speed as a supplier quality signal in its own right.
Offline behaviour deserved more of my attention. Factory floors have unreliable connectivity, and the product assumes a connection for autosave. I would want to know how the current design fails when the network drops mid-audit, and design that failure state explicitly rather than letting it be discovered.
The tablet-only edit constraint is right, and I would want to test its edges. It is the correct default. It also means a genuine transcription error found a week later has a more painful path to correction than it might need. I would want to design a visible, attributed amendment mechanism rather than relying on the constraint alone.
THE LESSON.
The hardest part of this project was not the interface. It was understanding one company's operation deeply enough to know which parts of it should stay human, which parts should become structured, and which parts the product could reliably take over.
The interface is the visible layer of a much larger organisational process. Designing it well meant spending months on the part nobody sees.
THE LESSON.
The hardest part of this project was not the interface. It was understanding one company's operation deeply enough to know which parts of it should stay human, which parts should become structured, and which parts the product could reliably take over.
The interface is the visible layer of a much larger organisational process. Designing it well meant spending months on the part nobody sees.