Direct answer: A dealer portal scope sheet defines six things before development starts — user roles, catalog and pricing, order approvals, payment and ledger handling, ERP integration ownership, and non-functional limits. Once built, the field sales order app should pass seven staging tests covering offline sync, ERP rate limits, payment-proof uploads, regional language rendering, geofenced visits, permission hard stops and battery or data consumption.
Most dealer portal projects do not fail because the screens look wrong. They fail because a field representative in Sriperumbudur loses signal mid-order, or because fifty reps sync at 09:00 and the ERP rejects the burst.
This guide gives you a scope sheet you can adapt and a staging test matrix you can run before go-live. It is written for owners and commercial heads at manufacturing SMEs, not procurement departments. If you are still choosing who builds the system, run the software vendor vetting checklist first.
Why Generic Dealer Portals Fail in Chennai's Industrial Belts
Cloud-only order apps assume connectivity that a shop floor or an industrial estate does not guarantee. A representative visiting a distributor near Ambattur or Sriperumbudur may work through dead zones for part of the day. If the app cannot hold a draft order locally, the visit produces a phone call and a paper note instead of a record.
Three other assumptions break in practice:
- Language and device reality. Field staff often carry mid-range Android phones and may prefer a Tamil interface. A layout tested only on a desktop browser will not reveal script rendering or keyboard problems.
- Payment proof handling. Dealers pay by NEFT, RTGS or UPI and send a screenshot. If the upload compresses the image until the UTR (Unique Transaction Reference) is unreadable, someone reconciles it manually at month end.
- Bulk sync behaviour. Morning beat plans and pending orders arrive together. Untested ERP rate limits turn a routine sync into a system-wide slowdown.
A custom build is not automatically better than a configured product. It is justified when your pricing tiers, approval rules or integration requirements cannot be expressed in an existing system. The point is to design for these constraints from the start, which is how JUHENZA's manufacturing software work begins.
The Dealer Portal Scope Sheet: 6 Core Modules to Define
Agree the boundaries in writing before anyone writes code. Each module below should list what is in scope, what is explicitly out, and how acceptance will be judged.
1. User roles and permissions
Define who can see and do what, in a table rather than a paragraph.
- Field sales representative: creates orders, views only assigned dealers, uploads payment proof, requests overrides.
- Dealer or distributor: views catalog and stock, places self-service orders, sees ledger and outstanding dues.
- Commercial head: approves credit overrides, sets pricing tiers, views regional dashboards.
- Operations or accounts: reconciles payments, corrects failed orders, exports reports.
State the permission model explicitly: role-based access control, one role per action, and a named owner for granting access.
2. Product catalog and pricing engine
- Tiered pricing rules, including whether tiers differ by dealer, region or volume.
- Real-time stock visibility and what "available" means when the ERP figure is stale.
- Handling of discontinued SKUs, minimum order quantities and unit conversions.
- Who maintains the price list, and how a price change reaches the app without a release.
3. Order management and approval workflows
- Draft saving, including drafts created offline.
- Approval routing by value, credit status or product category.
- What the representative sees while an order waits for approval.
As an illustrative calculation, if an approval chain has three steps averaging four hours each, an urgent order waits about twelve hours before dispatch planning begins. Automating a deterministic credit check can remove one step — but only if the ERP response is reliable and the rule is unambiguous.
4. Payment and ledger integration
- Outstanding dues and available credit displayed at order time, not on a separate page.
- Upload for NEFT, RTGS or UPI proof with the UTR captured as structured data, not only as an image.
- A hard stop when a dealer exceeds their credit limit, with a visible reason and an override request path.
Decide early whether the portal reads the ledger or writes to it. Two systems writing the same balance is a reconciliation problem waiting to happen.
5. ERP and third-party integrations
Name the system of record for each data type. A workable default: the ERP owns item masters, stock levels, pricing and ledgers; the portal owns draft orders and visit records; the ERP owns confirmed order status.
Then specify the contract — endpoints, request limits, retry policy, idempotency keys, error codes and the behaviour expected when a dependency is unavailable. The ERP, CRM and API integration planning guide covers this mapping in more detail, and our guide to failed syncs and duplicate records covers the recovery side.
6. Non-functional requirements
- Target devices: define the minimum Android version, screen size and memory you will support.
- Performance: set a load target for the order form on a realistic mobile connection, not office Wi-Fi.
- Availability: state what the app must still do when the ERP is down.
- Security: encryption in transit, session expiry, audit logs and access review.
- Data protection: if the system holds employee, dealer-contact or visitor personal data, allocate duties under India's Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 in the contract.
7 Critical Staging Tests for Field Sales Order Apps
Run these in a staging environment with representative data before go-live, and record who signed off each one. Vendor demonstrations are not tests.
Test 1: Offline-first order sync and conflict resolution
Scenario: a representative creates an order in a low-signal area, then regains connectivity.
What to verify: the draft persists locally and survives an app restart. On reconnection it syncs once, without duplicating the order or overwriting newer stock data. If an item went out of stock while the device was offline, the app explains the conflict and offers a next step rather than failing silently.
Offline behaviour is a design decision, not a library setting. The web.dev offline cookbook is a useful reference for the service-worker patterns involved.
Test 2: ERP API rate limiting and bulk retry
Scenario: fifty representatives sync beat plans and pending orders in the same fifteen minutes.
What to verify: the middleware queues requests and stays within the ERP's documented limits. Failed calls retry with backoff instead of flooding the endpoint. The queue drains without losing records, and operations can see depth and failures.
Deliberately simulate a timeout and a rate-limit rejection during the test. A retry policy that has never been exercised is an assumption.
Test 3: Payment proof upload and UTR capture
Scenario: a dealer pays by UPI and the representative uploads the screenshot.
What to verify: compression keeps the reference legible, the UTR is captured or entered manually, and the record links to the right invoice. Access to the image is restricted to finance and the assigned representative.
Test on the lowest-spec device you support. Image handling often passes on a flagship phone and fails on the phones your team actually carries.
Test 4: Regional language and keyboard rendering
Scenario: a distributor switches the portal or app to Tamil.
What to verify: script renders correctly on supported devices, input fields accept regional keyboards, and validation messages remain readable. Check truncation in buttons, table headers and status labels, since translated strings are often longer than the English originals.
Test 5: Geofenced visit validation
Scenario: a representative logs a dealer visit or requests a discount order.
What to verify: location capture works with the accuracy your policy assumes, and the app behaves sensibly when permission is denied or GPS drifts. Choose a radius you can defend — a tight radius in a dense estate produces false rejections, and a loose one proves nothing.
Test 6: Permission and credit-limit hard stops
Scenario: a representative tries to place an order for a dealer above their credit limit, or approve their own discount.
What to verify: the server enforces the rule, not just the interface. The action fails with a clear reason and an override request path. Attempting the same action through a direct API call must also fail.
Test 7: Battery and data consumption over a shift
Scenario: eight hours of use across roughly fifteen dealer visits.
What to verify: the app does not drain the battery before the shift ends, and background sync does not consume data disproportionate to the work performed. Profile on a mid-range device, and treat sync frequency as a configuration choice you can tune.
Set thresholds before the test — a pass/fail number agreed with the business, not a judgement after the fact.
Worked Example: Scoping a Distribution Portal (Illustrative)
This is a planning scenario, not a client result.
A mid-sized manufacturer in the Ambattur belt wants field order capture connected to its accounting system. During the workflow walkthrough, the team finds that dealers routinely order promotional combinations that do not exist as single SKUs in the ERP. Adding a bundle-mapping module to the scope sheet — and a test case for combined-item availability — prevents the reconciliation problem that would otherwise appear a month after launch.
The same discovery pattern applies to any distribution build: the scope sheet grows because the walkthrough surfaced a real exception, not because someone wanted more features.
Common Mistakes and Limitations
Designing only for the ideal state. A dealer with no outstanding orders and no recent purchases should still see something useful — frequent items, reorder shortcuts, or a clear explanation of an empty ledger.
Assuming clean master data. Legacy ERPs often carry duplicate dealer records and outdated price lists. Scope a data cleansing phase, and decide who owns corrections.
Treating an approval trail as speed. Automating capture does not compress a three-day internal approval. Software makes an existing bottleneck visible; it does not remove it.
Skipping the field pilot. One line or one region first, with real representatives and real dealers, surfaces more than another round of internal review.
Limitation: no scope sheet or test matrix guarantees adoption. A portal that is technically correct but slower than a phone call will be worked around.
Frequently Asked Questions
What is a dealer portal scope sheet?
A dealer portal scope sheet is a short document that fixes the features, user roles, integration points, exclusions and acceptance criteria for a B2B distributor platform. It exists so the business and the development team agree on what will be built before coding starts, and so later change requests can be judged against a baseline.
How long does a custom field sales app take to build?
A focused single-purpose application commonly runs eight to fourteen weeks from discovery to handover. ERP integration complexity, offline requirements and approval logic move that range. A multi-role platform with dealer self-service, analytics and ledger features takes longer, and the estimate should be revised after discovery rather than fixed before it.
Can the field sales app work without an internet connection?
Yes, if offline-first behaviour is written into the scope. The app caches the assigned catalog and dealer list, accepts draft orders locally, and syncs when a connection returns. Decide in advance what happens to an order whose price or stock changed while the device was offline.
How should ERP integration failures be handled in testing?
Simulate them. Time out a call, reject a request for exceeding a rate limit, return a partial response and drop the connection mid-sync. Verify that the system queues or fails visibly, logs the error with enough context to act, and does not lose the representative's data.
Is a custom dealer portal better than an off-the-shelf product?
It depends on how much of your process is standard. If your pricing, approvals and integration needs are conventional, configuring an existing product is usually cheaper. Custom work earns its cost when the workflow genuinely differs, or when an integration cannot be made reliable inside the product. Compare total cost of ownership, including migration and workarounds, rather than licence price alone; our pricing page explains how JUHENZA scopes and quotes work.
Who should own the app, the data and the accounts?
Your business should own the repository, cloud accounts, domain and production data, with a third-party licence list attached. A portal that only the vendor can deploy is a continuity risk regardless of how well it was built.
Define the Scope Before You Compare Vendors
A dealer portal succeeds on the exceptions: the offline order, the burst sync, the payment proof nobody can read. Write the scope sheet, run the seven tests, and keep the evidence.
If you are planning a dealer portal or field sales application in Chennai or elsewhere in Tamil Nadu, start by documenting the operating problem. Share your project brief with JUHENZA and we will respond with questions, assumptions and boundaries before a price.
References
- Nielsen Norman Group — Response Times: The 3 Important Limits, Jakob Nielsen, 1993, revised 2014.
- Google for Developers — The Offline Cookbook, web.dev.
Scope figures, timelines and cost examples in this article are planning guidance, not quotations. Regulatory mentions are informational, current as of November 2026, and not legal advice.