Start with one process
We start with one recurring problem, agree who owns it and what counts as done, test it with real examples, and agree who runs it after launch.
Record short, specific answers before choosing a product or requesting a build.
| Input | What to record |
|---|---|
| Frequency | How often does the work happen? |
| Current handling time | How much staff time does one case usually take? |
| Exceptions | Which cases do not follow the usual steps? |
| Existing tools | Which systems, inboxes, files, or forms hold the information? |
| Process owner | Who handles the work now and can explain the current process? |
| Required approvals | Which actions or decisions always need a person? |
| Ongoing costs | Which software, provider, support, or maintenance costs need review? |
| Manual fallback | How will the work continue if the new process pauses? |
Bring the current steps, systems, owner, approvals, common exceptions, and manual fallback. First check whether a product setting, standard connection, or process correction can solve the problem.
You get: The problem, included process, owner, baseline, known exceptions, and recommended next step.
The written scope should identify systems, inputs, actions, permission limits, test cases, acceptance reviewer, and excluded work. Realistic test records need an approved private handling method.
You get: The tested workflow or exchange, test results, unresolved exceptions, and acceptance decision.
Before launch, agree the operational owner, monitoring, failure path, manual fallback, and change process. State which accounts, code, data, configuration, operating notes, support, and charges the agreement covers.
You get: Ownership and access records, operating notes, support terms, and a review date.
| Dependency | Why it changes the work | Primary owner |
|---|---|---|
| Number of systems | Each connection needs access, mapping, and tests. | Scope owner |
| Access readiness | Missing accounts, permissions, or test environments delay testing. | System owner |
| Data cleanup | Inconsistent fields and identifiers need decisions before reliable automation. | Business data owner |
| Approval complexity | More reviewers and decision paths add cases to design and test. | Business process owner |
| External testing | A buyer or provider controls its test windows and final acceptance. | External party |
Keep a person on money, unusual pricing, customer commitments, low-confidence interpretation, and failures without a safe recovery path. The proposal should use the known dependencies rather than a generic timeline.
Related: System integrations · EDI, cXML, and PunchOut · Services
Check existing settings, connectors, imports, and exports first. A process correction or standard integration may solve the problem without a custom build.
Describe the steps, process owner, systems, common exceptions, required approvals, and the result you need. Keep credentials and private customer data out of the public form.
Missing access or test environments delay testing. Inconsistent data needs cleanup decisions. More approvals add test cases. A buyer or provider controls its own testing and acceptance schedule.
Agree the ordinary cases, expected failures, approval rules, and reviewer before building. The reviewer checks the resulting records and exception handling. An external trading partner may also need to accept an integration.
Agree who monitors the system, handles failures, and makes changes. Record the manual fallback, account and data responsibilities, what support includes, and any recurring charges in the scope.
Bring one repeating problem. We will help determine whether a controlled system is a sensible next step.
