ONDC merchant onboarding is not a single form-filling event. It can involve seller-network-participant selection, business and tax details, catalogue creation, location setup, payments, logistics, consent, and technical validation. A merchant may abandon the process because a document is rejected, a field is unclear, a catalogue fails validation, or a support team cannot resolve an error quickly.
AutoResearch can make this investigation more systematic. Used properly, it helps a team collect evidence, compare cohorts, identify recurring failure patterns, and test whether a process change actually improves activation. It should not be treated as an autonomous decision-maker or as a substitute for merchant interviews. The strongest workflow combines structured event data, qualitative feedback, privacy controls, and controlled experiments.
What AutoResearch should answer
Start with specific questions rather than asking the system to “find bottlenecks”. Useful questions include:
- At which onboarding stage do merchants wait the longest?
- Which errors most often lead to abandonment or repeated support contacts?
- Do first-time digital sellers struggle more than experienced e-commerce merchants?
- Does onboarding performance vary by state, language, device type, category, or seller-network participant?
- Which intervention improves time to first successful catalogue upload and time to first order, not merely form completion?
Define the outcome before collecting data. Suitable primary metrics include completion rate, median and p90 time to completion, stage-level conversion, rework rate, support resolution time, and activation within 7 or 30 days. Also decide what would count as a meaningful improvement—for example, a 20% reduction in p90 verification time without increasing rejection rates.
Teams building an automated support layer can also compare this workflow with WhatsApp Native Onboarding: A Practical Guide for India, particularly when merchants prefer assisted onboarding over a web dashboard.
Step 1: Map the actual onboarding journey
Document every state transition in the current process. A practical map may include:
1. Lead or invitation created.
2. Merchant account and consent completed.
3. Business identity and tax information submitted.
4. Bank or payment details verified.
5. Catalogue, pricing, images, and inventory uploaded.
6. Fulfilment, pickup, and serviceability configured.
7. Technical checks completed.
8. Merchant approved, published, and activated.
For each stage, record the expected input, responsible system or team, success condition, rejection reason, retry path, and timestamp. Do not rely only on a funnel dashboard: a merchant can appear “complete” while remaining unpublished or unable to receive orders.
Step 2: Build a clean, privacy-safe dataset
Export event-level data rather than only daily totals. Useful fields include:
- A pseudonymous merchant ID and onboarding cohort date.
- Stage name, event timestamp, status, retry count, and error code.
- Seller-network participant, geography, category, language, device, and channel.
- Document or catalogue rejection reason, with sensitive values removed.
- Support ticket type, first-response time, resolution time, and outcome.
- Date of publication, first catalogue success, first order, and first settlement.
Separate personally identifiable information from analytical tables. Hash or tokenise identifiers, restrict access by role, define retention periods, and exclude raw documents, bank details, phone numbers, and unnecessary free-text data. Confirm that the proposed analysis aligns with the organisation’s privacy notices, contracts, and applicable Indian data-protection obligations.
Before analysis, fix basic data quality issues: duplicate events, inconsistent timezone handling, missing stage exits, impossible durations, and error codes that changed between releases. Maintain a data dictionary so AutoResearch does not confuse “submitted”, “approved”, “published”, and “active”.
Step 3: Give AutoResearch a bounded research brief
A strong brief specifies the dataset, time window, definitions, comparison groups, and required evidence. For example:
> Analyse onboarding events from January to March 2026. Calculate stage conversion, median and p90 duration, retries, and abandonment for each step. Compare new-to-digital merchants with experienced sellers and report only findings supported by at least 50 merchants. For every finding, cite event counts, affected cohorts, possible confounders, and a recommended validation test.
Ask for tables and reproducible queries, not just a narrative summary. If your implementation uses the open-source Karpathy-style AutoResearch workflow, place the analysis script, evaluation metric, experiment configuration, and output artifacts under version control. Guidance on using AutoResearch for India Stack documentation is useful when the investigation depends on evolving protocol or integration documentation.
Step 4: Identify bottlenecks with multiple lenses
Use at least four analyses:
- Funnel analysis: measure the share progressing from one stage to the next.
- Duration analysis: compare median and p90 waiting time, since averages hide long-tail delays.
- Error analysis: rank errors by frequency, repeat attempts, and downstream abandonment.
- Cohort analysis: compare geography, language, category, participant, device, and onboarding channel.
Add a path analysis for merchants who retry or move backward. A high retry count may indicate unclear instructions rather than a technical failure. A high drop-off after verification may indicate that catalogue setup, images, inventory, or logistics is the real barrier.
Do not infer causality from correlation alone. A participant with slower onboarding may serve a different merchant mix or have more complex verification rules. AutoResearch should flag these relationships for investigation, not label them as causal facts.
Step 5: Validate findings with merchants and operators
Select a small sample from each major failure pattern. Review support tickets, screen recordings where consent exists, and structured interviews with merchants, onboarding agents, and technical teams. Ask merchants to describe what they expected at the point of failure, what they tried next, and whether the error message was actionable.
This step often exposes gaps that event logs miss: unclear regional-language instructions, documents that are technically valid but hard to photograph, unreliable low-bandwidth flows, or confusion between ONDC roles. If the core issue is model or data quality, review methods for fine-tuning a model with ONDC catalogue data, while keeping merchant data governance separate from model experimentation.
Step 6: Convert evidence into ranked interventions
Create an intervention backlog with five fields: bottleneck, evidence, proposed fix, owner, and success metric. Rank each item by expected merchant impact, implementation effort, risk, and confidence in the diagnosis.
Possible interventions include:
- Showing a stage checklist with examples of acceptable documents.
- Replacing generic errors with field-level guidance and a retry path.
- Saving progress for low-connectivity users.
- Adding regional-language assistance or voice support.
- Validating catalogue fields before submission.
- Routing complex cases to trained human agents.
- Pre-filling known information only where consent and accuracy are clear.
Avoid optimising for a faster “completed” status if it increases later rejection, cancellation, or support load.
Step 7: Test changes and monitor guardrails
Use an A/B test where operationally and ethically appropriate; otherwise, use a phased rollout or pre/post comparison with a matched cohort. Define the primary metric, guardrails, sample size, test duration, and stop conditions before launch.
Track completion rate, p90 duration, rejection and rework rates, support contacts, publication success, first-order conversion, cancellation, and merchant satisfaction. Segment results by language, geography, participant, category, and device so an overall improvement does not conceal harm to a smaller group.
Run AutoResearch on a fixed schedule and preserve each run’s dataset version, prompt or configuration, code commit, assumptions, and output. This makes the result auditable and prevents teams from changing definitions after seeing the outcome.
Common mistakes to avoid
- Treating missing events as successful completion.
- Using averages without p90 or cohort breakdowns.
- Feeding sensitive merchant data into an unapproved tool.
- Ranking bottlenecks only by volume instead of merchant impact.
- Confusing support-ticket frequency with root-cause frequency.
- Launching fixes without a baseline and guardrail metrics.
- Assuming an AI-generated explanation is evidence.
A practical 30-day rollout
In week one, define the journey, metrics, owners, and privacy controls. In week two, clean the event model and run a baseline analysis. In week three, validate the top two or three findings with merchants and support teams. In week four, launch one low-risk intervention, measure it against the baseline, and document the result.
The objective is not a sophisticated report. It is a repeatable loop: observe, explain, test, measure, and improve. For teams working across ONDC and other Indian commerce systems, related model-building work such as using Hugging Face MCP with ONDC seller data should follow the same discipline around data minimisation, reproducibility, and evaluation.