Order Entry Automation: Client Proposal

Prepared for: RCB Awards

Order Entry Automation Overview

RCB asked us to look hard at automating order entry. We've done our initial due diligence — with our own eyes and with our AI tooling, using the intake notes, the Antera API documentation, and the order-entry workflow as described. This document recaps the project as we understand it, what it would do for RCB, and how we'd get from here to a firm price. The expected build lands in the $15,000–$30,000 range. The next step we're proposing is a $3,000 scoping engagement that produces a complete project specification and a firm quote.

Project Vision

Today: purchase orders arrive by email — a PDF or Excel PO plus artwork — into the shared orders inbox. Someone looks up the customer in Antera, clones a previous order (because it carries the production notes that matter), and then retypes every field by hand: PO number, addresses, ship date, in-hands date, event date, shipping method, and each line item's components — a single name badge is three components. Several people do this, each a little differently. As of this week, that work comes back in-house from the offshore team.

After: orders still arrive exactly the way they do now — distributors change nothing. The system reads each PO as it comes in, finds the closest previous order from that customer (so the production notes carry forward), and pre-fills the entire order. A person reviews instead of types: first "is this the right starting point?", then "approve the finished order." The order lands in Antera, entered the same way every time. Order entry becomes a few minutes of review per order instead of keying — roughly a 30-minute-a-day review job.

What RCB gets out of it

• Keying becomes reviewing. The tedious transcription disappears; humans check pre-structured work instead of reading and retyping simultaneously. Errors drop for the same reason.

• One consistent intake. Every order enters Antera the same way, regardless of who's on duty — which matters most right now, with order entry transitioning in-house.

• Nothing falls through the cracks. Every incoming PO is tracked from arrival to entered-in-Antera, with a visible trail: what came in, what was extracted, what was written, who approved it.

• Easier handoffs and training. A new person reviews orders on day one instead of learning a keying procedure; the system carries the how-we-enter-orders knowledge.

• Antera stays the boss. This wraps around Antera — it doesn't replace it, doesn't compete with it, and doesn't become a second place your data lives.

Features

1. One intake point — connects to the existing shared orders inbox; no new email address, no change for distributors.

2. PO reading — handles the PDFs and Excel files distributors actually send, including name lists; extracts every Antera-ready field.

3. Clone-matching — finds the closest prior order from that customer so production notes, components, and specs carry forward, the way the team already works.

4. Two-step review queue — a simple web page: confirm the right starting point, then approve the completed order. Anything the system can't read confidently goes to a "needs a human" lane — nothing is ever guessed silently or dropped.

5. Writes into Antera through Antera's official API — either creating the order outright or filling in everything after a one-click create, depending on what Antera enables (see open questions).

6. Artwork staged with the order — artwork files and Dropbox links are captured and kept with the order for the operator; automatic attachment into Antera is a later add-on.

7. Status and receipts — a page showing each order's journey from inbox to Antera.

8. Simple sign-in — staff sign in with a code sent to their email; no passwords to manage. Adding or removing a person is a minutes-long list edit, and every approval is logged to the person who made it.

What it looks like in operation (deployment shape)

It's a private web application: staff open a web page in their browser, from the office or anywhere. There is nothing to install on anyone's computer and nothing to maintain. It runs in RCB's own account with a top-tier cloud provider (Cloudflare) — Rogue Agents sets it up, configures it, and hands over the keys; RCB owns it. At RCB's volume the expected running cost is likely zero dollars per month. (Cloudflare's business model is massive web applications for large corporate customers. Order Entry fits within their generous free tier, not using enough of their resources for them to need to bill RCB.) Orders are processed within a few minutes of arrival, which matches how order entry actually works.

Project Scoping: the $3,000 Project Package

This proposal is the result of goodwill homework by Rogue Agents on behalf of RCB. To turn it into a firm commitment, the next step is a paid scoping engagement: $3,000, enabling Rogue Agents to deliver the Project Package:

1. Product Requirements Document (PRD) — describes what the system does, in RCB's terms, with success measures (time per order, error rate) agreed up front.

2. Technical Architecture Document (TAD) — how it's built: the architecture, security, where data lives, and the Antera integration approach, resolved against Antera's answers.

3. Implementation Plan — timeline, milestones, the rollout approach (the final week runs in shadow mode: for instance, the system processes the real inbox alongside the team and we compare its output to what humans key, going live when the match rate is boring), acceptance criteria, and warranty/support terms.

4. A firm quoted price for the build — expected in the $15K–$30K range.

Terms: if RCB proceeds with the full build, the $3,000 paid for scoping is credited towards the full build cost. If not, the Project Package is RCB's to keep — it's a complete specification any competent shop could build from. For builds toward the upper end, we can structure the work in two or three milestones with a check-in at each, so RCB is never committed further than the next milestone.

Our working assumptions

These are the engineering team's defaults — pulled from architectures we've shipped many times. Most will be invisible to RCB; they're listed so they can be checked rather than discovered. Any that are wrong get fixed in the scoping engagement; if one is a deal-breaker, better to find out now.

1. Antera remains the single source of truth for orders. Orders live only in Antera; the distributor display systems (SAGE, ESI) are product/display channels and are untouched by this project.

2. Scope boundary: this system covers PO-arrives-by-email through order-correctly-entered-in-Antera. Everything downstream — proofing, distributor approval, sourcing, production — continues exactly as today.

3. The Antera API can fully populate an order (items, components, charges, decorations) — verified against their public API specification. Whether it can originate an order is Antera's pending answer; both branches fit inside the quoted bucket. If the answer is no, a person clicks "create" (or "clone") in Antera — about 30 seconds — and the system fills in everything else.

4. A signed Antera API agreement (RCB action, no fee per Antera) is in place before the build starts; its paperwork lead time sits on the critical path.

5. The PO inbox stays where it is — the existing shared Outlook inbox. We connect through Microsoft's standard interfaces or a simple forwarding rule; no email migration, no change to how distributors send.

6. A human reviews every order, at least initially. Any future auto-approval of routine repeat orders is a deliberate, opt-in decision after the system has earned trust — not a default.

7. Hosting: the system runs in an RCB-owned Cloudflare account that we set up and configure; RCB owns and controls it. No servers in RCB's office; nothing hosted on Rogue Agents' infrastructure.

8. Where data sits: in-flight order data, the review queue, and the activity log live in that RCB-owned cloud account (US-based). Antera remains the permanent system of record — we pull from Antera and write into Antera; the system doesn't become a second home for the business data.

9. Users: roughly six named staff. Sign-in by emailed one-time code (no passwords stored anywhere), refreshed every two weeks; the user list is a simple edit; per-person audit trail of approvals.

10. Standard security: encrypted in transit and at rest; the Antera API credential is scoped to the minimum needed and held in the RCB-owned account; no end-customer payment data flows through the system at all.

11. Duplicate-safety is built in: a retry, a re-sent email, or a re-run must never create the same order twice.

12. PO formats vary by distributor. The parser is built and tested against 3–5 real sample POs from different distributors before anything is firm; the \~80% repeat-order rate and human review on every order are the safety nets while coverage grows.

13. Artwork in v1 is staged, not auto-attached — files and links are captured with the order for the operator; automatic attach into Antera's file handling is a candidate later add-on, not in this scope.

Open questions

The $3,000 scoping turns the following questions into knowledge. Several of these may change the shape or quoted price of the build; none of them are expected to change the bucket.

1. Antera's answer: can an order be created — or cloned — via the API or a bulk-import mechanism? (Briana's question to Antera, already in flight; clone might fit RCB's workflow even better than create.)

2. Volume baseline: how many orders per day come through, and what was the offshore team's throughput? (Sets review-queue design and the success measures.)

3. Sample POs: 3–5 real POs from different distributors (redacted is fine).

4. One hour watching an operator key a real order — especially the clone-selection step and where the production notes come from.

5. Who reviews? After the in-house transition, who owns the review queue day-to-day, who's the backup — and do they want a ping when orders are waiting, or is checking the queue part of the morning routine?

6. Inbox specifics: who administers the shared orders inbox? Are we able to add a connection or forwarding rule to it?

7. Data-location comfort: any concerns with the in-flight data living in a US cloud account (RCB-owned)? If RCB prefers different arrangements, that's a cost variable, not a blocker.

8. What does success look like to Briana? Minutes per order? Error rate? Same-day entry? We'll write the agreed measure into the PRD.

9. Parse-failure tolerance: at the start, what share of orders falling to the "needs a human" lane is acceptable?

10. Artwork expectation check: is staged-with-the-order sufficient for v1, or is auto-attach into Antera a must-have? (Changes scope and price if must-have.)

11. Paper-trail requirements: any audit, insurance, or compliance expectations the activity log should be designed to serve?

12. Technical validation: will the architecture we're proposing actually do the job? The scoping engagement proves the riskiest pieces against reality — reading real POs at acceptable accuracy, writing a real order into Antera with a real credential, connecting to the real inbox — before any build dollars are committed.

How the scoping engagement runs

1. Inputs (mostly client-side, days not weeks): signed Antera API agreement + credential or sandbox · Antera's order-create answer · 3–5 sample POs · the operator shadow hour · a short field-mapping workshop (RCB's Antera fields ↔ PO fields ↔ component conventions).

2. We resolve every assumption and open question above into decisions — interviews, the shadow hour, API verification against a real credential.

3. We deliver the Project Package — PRD, TAD, Implementation Plan, firm quote — typically within one to two weeks of the inputs being in hand.

4. RCB decides with a fixed price and a complete spec in hand: build with us (the $3,000 then credits to the build), build later, or take the package elsewhere.