The request
“What needs restocking?”
A distributor wants to check inventory against a threshold without exporting a spreadsheet each time.
Partner walkthrough
From a lab test to a client’s daily workflow.
Follow a read-only inventory assistant through delivery. This guide uses the workflow exercised in the partner pilot; the client scenario and inventory data are fictional.
The software
Read, compare, report.
An approved API supplies inventory. A script finds low-stock items and returns a structured result to the agent.
The boundary
No purchasing permissions.
This version can report low stock. It cannot place orders, send messages to suppliers, or update inventory.
The delivery path
One version.
A result you can verify.
The text-only starter file in your workspace is the first exercise. The inventory example adds an external API after you understand the basics.
The lab entitlement and supported integrations depend on your pilot setup. Confirm them before promising a workflow to a client.
-
Scope a small result
For the inventory example, the input is a stock threshold. The output is a list of items below that threshold. Reading inventory is in scope; creating purchase orders is not.
Decide what the workflow may read, what it may change, and how a person checks its answer.
-
Prepare your lab
Open Development lab in your partner workspace. Check the credit allowance and expiry, prepare the agent, and wait for launch to complete.
Your lab is separate from a client workspace. Use sample data and credentials approved for testing.
-
Try the starter package
The software workspace includes a downloadable Text helper package. Upload it and run its word-count test to learn the release process without connecting an external service.
Once that passes, adapt the package structure for your inventory workflow, including its API permissions and expected test output.
-
Test the inventory check
Add the lab API credential separately, using the alias declared by the software. Upload a version and run its tests against the intended sample inventory.
If a test fails, inspect the result, correct the package, and upload a new version. Never treat an upload alone as a successful test.
-
Agree on the client engagement
Create the client offer with the agreed hosting, implementation, and service prices. Share the invitation. The client reviews the offer and grants access with an expiry.
Client access and payment requirements must be satisfied before work can proceed. The partner cannot approve on the client’s behalf.
-
Prepare and submit the release
Choose the client, target agent, and tested software version. Prepare the delivery and review its result. Client API credentials are configured separately from lab credentials.
The client sees the prepared release and requested permissions. Their approval applies to the exact release they reviewed.
-
Verify and support
Wait for the delivery to finish successfully, then check the workflow with the client. Handle requests and quote additional work from the client workspace.
A change that adds ordering or other system writes needs a new scope, tests, and release approval.
Where to take it next
Start with a useful, bounded task.
These are scoping examples to discuss with OpsRev. Integration availability and implementation effort need to be confirmed for each client.
Reconciliation review
Compare two approved data sources and flag unmatched entries for a person to review. Start with a report; scope accounting writes separately.
Partner work: field mapping, matching rules, representative tests, and exception handling.
Follow-up preparation
Identify stale client records and draft the next action. Add sending permissions only after agreeing on recipients and approval rules.
Partner work: CRM integration, timing rules, message quality checks, and client review.
