Client Handbook: On-Site ERPNext Requirements Gathering

What to Expect

This handbook walks you through our on-site discovery engagement — what we'll do together, how to prepare, and what you'll walk away with.

Before we design or build anything in ERPNext, we invest time understanding how your business actually runs: the workflows, the workarounds, the things your team does from memory that never made it into a process document. In our experience, the most valuable insights come not from slide decks but from watching a real order move through your system live — that's when the real gaps surface.

The engagement has three phases: before, during, and after the visit.

Why We Recommend Doing This In Person

Remote discovery works for simple systems. For manufacturers and operations-heavy businesses, it consistently misses things.

When we ran discovery sessions with a rugged laptop manufacturer recently, some of the most important design decisions came out of moments that only happen in a room together — a production supervisor pointing to a whiteboard and saying "this is where we lose track of jobs," a quality manager pulling up an Excel log that nobody outside the department knew existed, an offhand comment about a label printer that turned out to affect the entire receiving workflow. These moments don't happen on a video call.

Being on-site also means we can walk the floor, see where things physically happen, and talk to the people who actually run the processes — not just the managers who describe them. The result is a requirements document that reflects how your business really works, not how it's supposed to work on paper. That's what makes the build go smoothly.

Phase 1: Before the Visit

A little preparation here pays off significantly during the sessions. The goal is to make sure we spend our time together making decisions, not gathering basic context.

Your checklist:

• [ ] Name your core team. You need one person who can make scope and priority decisions on the spot, plus a lead from each department the system will touch (sales, operations, finance, purchasing, quality, etc.).
• [ ] Identify a technical liaison. This is the person who knows your current system's data, reports, and quirks — including the workarounds that everyone uses but nobody talks about.
• [ ] Map your current tools. List every system or tool in use today — ERP, accounting, spreadsheets, shared drives, paper logs — and roughly how information moves between them. Don't worry about making it formal; a rough list is enough.
• [ ] Write down your pain points. What slows your team down? What do people do manually that feels like it shouldn't be manual? What breaks down at month-end or during a big order? No polish needed — honest and rough is more useful than clean and incomplete.
• [ ] Gather your key documents and reports. Bring the reports, forms, and documents your team relies on most day-to-day: pick lists, shipping logs, purchase orders, quality checklists, certificates of compliance, anything your team prints or fills out regularly.
• [ ] Share any existing process diagrams. If you've sketched out your workflow — even in PowerPoint, on a whiteboard photo, or in a simple flow tool — share it ahead of time. It gives us a starting point to validate and build on.
• [ ] Send us a business overview and sample documents before the visit. A one-page summary of what your business does, who your customers are, and what a typical order or job looks like goes a long way. Pair it with two or three real examples of the documents your team produces — a completed sales order, a purchase order, a packing slip, a quality record, whatever is central to your workflow. Seeing real paperwork before we arrive means we walk in already thinking in your language, and the first session moves faster because of it.
• [ ] Declare your compliance obligations upfront. If your business operates under specific regulatory requirements (government contracts, quality certifications, cybersecurity standards, industry-specific rules), tell us before the visit. These shape the design from day one.
• [ ] List your integrations. What external systems must connect to ERPNext? Accounting software, label printers, shipping carriers, customer portals? Note what you know about each one — even partial information helps.
• [ ] Think about your phase priorities. What absolutely must be live on day one? What could wait three to six months? Having a rough answer to this before we arrive saves significant scoping time.
• [ ] Confirm recording consent. We record sessions so nothing gets lost in notes. Confirm internally who needs to be looped in on this before we arrive.

Phase 2: During the Visit

Sessions are organized by department

We run focused sessions by function rather than one long open-ended meeting. Each session covers a specific area — sales and order entry, operations and production, purchasing and receiving, quality, shipping, finance — and includes only the people relevant to that area.

• [ ] Confirm the agenda and which team members attend which session before the visit.
• [ ] Block your core team's calendars for the full duration. Partial availability is the most common cause of sessions running long or missing critical context.

Show us, don't describe it

The single most valuable thing you can do during the visit is walk us through real workflows live in your current system — not describe them from memory.

• [ ] Pick one or two real orders or jobs to use as examples for each session. Walk us through them start to finish: how the order came in, how it moved through your system, what documents got created, where it slowed down.
• [ ] Show us the exceptions and edge cases, not just the clean path. The unusual situations that come up regularly — a part that needs re-inspection, an order that spans multiple purchase orders, a customer who requires extra documentation — are often where the real design decisions live.
• [ ] Show us your manual workarounds. If your team keeps a spreadsheet on the side, maintains a paper log, or does something in a chat tool because the system doesn't support it — show us. These workarounds are exactly what we're here to solve.

Expect a lot of "why" questions

We'll ask why steps exist. This isn't to challenge your team — it's to understand which steps are genuine business rules, which are workarounds for system limitations, and which are habits that can be simplified in the new system.

• [ ] Encourage your team to answer honestly, including "we've always done it this way" or "I'm not sure." Those answers are genuinely useful.

We'll align on terminology early

Every business has its own vocabulary for core entities and processes. We'll map your terms to ERPNext terms live during the first session so everyone is speaking the same language for the rest of the visit.

• [ ] Before the visit, jot down the terms your team uses internally for key things: what you call a job, an order, a part, a shipment, a job packet, a traveler — whatever your language is. We'll build the terminology map from there.

We'll sketch the future state together

For each major workflow, we'll draw the proposed future process on a whiteboard during the session so your team can react and correct it in real time. Nothing on the whiteboard is final — it's a draft to argue with.

• [ ] Come ready to push back. If something we sketch doesn't match how your business actually works, say so immediately. It's much faster to correct a sketch than to correct a built system.

Phase 3: After the Visit

Within an agreed window after the visit, you'll receive:

• [ ] An open items list — questions and decisions that need an answer from your team before design can be finalized, with a named owner for each item.
• [ ] Current vs. future workflow specs — for each major process, how it works today and how it will work in ERPNext, with the reasoning behind each proposed change.
• [ ] The Requirements Document — a structured, field-level specification covering every module in scope: the data (masters), the transactions and their workflow states, the reports, and the printed documents your team needs. This is the document that governs the build.
• [ ] Process flow diagrams — visual swimlane diagrams for each major workflow, showing the sequence of steps, decision points, and roles involved.
• [ ] A prioritized phase plan — requirements organized into Must Have / Should Have / Could Have / Not This Phase, with clear rationale for each decision.
• [ ] A risk and assumptions log — anything flagged as a risk, an open assumption, or a dependency on your team or a third party.

Your action items at this stage:

• [ ] Review the open items list and assign owners internally. Unresolved open items are the most common cause of build delays.
• [ ] Validate the current-state workflow specs. Flag anything we got wrong — accuracy here prevents rework later.
• [ ] Confirm or adjust the phase priorities. If your business priorities have shifted, now is the time to say so before the build begins.

Tips for Getting the Most Out of This

Send the people who do the work, not just the managers. The person who runs a process daily knows details that are genuinely invisible a level up. Both perspectives matter, but the operational detail is what drives design decisions.

Don't pre-filter your pain points. Even small daily annoyances can point to larger underlying issues. If your team loses thirty minutes a day tracking down a status, that's worth surfacing.

Show us the things you're embarrassed about. The manual spreadsheet nobody wants to admit exists. The paper log that lives in one person's desk. The process that only works because one person has it memorized. These are the things ERPNext is designed to replace — and we can't design around them if we don't know they exist.

Be open to simplification. If a process looks overly complicated, we'll often suggest simplifying it. This is usually a sign that a system limitation created complexity over time — not that your team has been doing something wrong.

Keep your core team consistent across sessions. Context carries over between sessions. When the same people are in the room across multiple sessions, decisions compound and go faster.

Appendix: Templates and Reference

Sample Multi-Day Agenda

Must-Have vs. Wants Prioritization

Use this format to separate what must go live on day one from what can follow.

Must Have — the system cannot go live without this. Want — valuable, but the business can operate without it on day one.

Open Items Log

Current vs. Future Workflow Template

Workflow name:

Current state (today) - Step-by-step description of how the process works now - Systems and tools involved at each step - Known pain points and workarounds

Future state (proposed in ERPNext) - Step-by-step description of the proposed process - ERPNext modules and doctypes involved at each step - Why this change is being made

Risk, Assumption & Dependency Log