BiRootFDE
中文

FORWARD-DEPLOYED ENGINEERING

AI for real operations.

Not another chat box. Our engineers sit inside your operation: they read the email and paperwork you get every day, learn your pricing rules and exception handling, then connect agents to the systems you already run — customs filing, terminal portals, ERP, messaging, the operator’s own desktop. Judgement calls stay with your people, and every step leaves a record.

Talk about your operationSee client work

A real customs workflow

J.D. USA
  1. 01

    Client email arrives

    B/L, invoice and packing list across several mailboxes

    AGENT
  2. 02

    Documents parsed and grouped

    Linked into one shipment by consignee and B/L

    AGENT
  3. 03

    Licensed broker reviews

    Commodity, HS code and filing details confirmed by a licensed broker

    HUMAN
  4. 04

    Filed in the customs system

    Entered through the existing interface, with an audit trail

    AGENT
Illustrative diagram, drawn from the customs brokerage engagement

You will probably recognise a few of these

  • ?

    Processes are long and fragmented, and nobody has time to fix them

  • ?

    New hires take months, experienced staff leave, and the know-how walks out with them

  • ?

    Too many tools, numbers that disagree, and no single source of truth

  • ?

    The same customer questions, all day, every day

  • ?

    Relationships and conversations live in chat apps, unmanaged and unsearchable

  • ?

    Lead flow depends on ads and personal networks, so it is neither stable nor predictable

These are the ones we run into most often on site, not an exhaustive list.

BY INDUSTRY

Work we have done

Each case states the same things: how it ran before, what we built, which systems it touches, which judgement stays with your people, what you get, and how far along it is.

Customs brokerageJ.D. USAUS customs broker

Three hundred entries a day, five people, thirty years of hand-built practice.

  • 30+ years in business
  • A team of five
  • 300+ entries a day

How it ran before

Clients send bills of lading, invoices and packing lists to several mailboxes. Staff download each attachment, work out the commodity and HS code by hand, key it into NetCHB field by field, then book it again in desktop QuickBooks. NetCHB has no public API, so everything between the three systems moves by hand. The team is at capacity, which caps the business.

What stays with your people

Commodity, HS code and filing details are always confirmed by a licensed broker before submission.

What we built

  • An intake agent that groups scattered attachments into one shipment by consignee and B/L
  • Document parsing and field extraction, with the broker’s own judgement rules written into a playbook
  • A NetCHB operation tool that writes through the same interface a human uses — no API required
  • Engineering and operations documentation, so handover and debugging do not depend on one person

Systems involved

NetCHBQuickBooksEmail (Yahoo / Gmail / Hotmail)

Deliverables

  • Customs agent and rules playbook
  • NetCHB operation tooling
  • Engineering and deployment documentation
Engineering work · build and deploy records
Customs operations demo ↗

Build and deployment records are complete; production coverage is confirmed step by step rather than claimed as end-to-end automation.

Drayage and truckingNature Brother TruckingWest Coast drayage and delivery

Checking containers should not be the longest job of the day.

  • Across multiple terminal and carrier portals
  • Dispatch and quoting in one tool
  • Runs on the operator’s own machine, reusing existing logins

How it ran before

Dispatchers click through terminal and carrier portals container by container, copy the result into a spreadsheet, then phone or message the drivers. Portals change layout, demand verification and drop the session, so it all starts over. Pricing rules live in a senior dispatcher’s head, and every new hire relearns them.

What stays with your people

Assignment, price changes and customer commitments stay with the dispatcher; the agent fetches, fills and records.

What we built

  • A container-status agent across terminal and carrier portals, with verification and failures handled in one place
  • A dispatch workspace where container status, assignment and quoting move together
  • A Windows desktop connector that executes on the operator’s own machine, reusing their existing sessions
  • Operating rules written down as playbooks a new dispatcher can follow

Systems involved

Terminal portalsCarrier portalsOdooWeComLocal Chrome

Deliverables

  • Container-status and dispatch agents
  • Dispatch workspace (web)
  • Windows desktop connector with a release process
  • Operating playbooks and runbooks
In production
Dispatch tool (access required)

The tooling is in daily use; later contract scope is still being agreed, and contracted scope is not presented as delivered scope.

Overseas warehousing and 3PLAllways Express LogisticsDevanning · fulfilment · long-term storage

Cross-system reconciliation, broken into steps you can inspect.

  • Three lines: devanning, fulfilment, storage
  • Property broker — capacity comes from outside carriers
  • Serving cross-border e-commerce and Amazon FBA

How it ran before

Proof of delivery, carrier confirmations, the warehouse system and customer invoices each hold their own version of the truth. When they disagree, someone works back through paperwork, email and chat line by line. Discrepancies surface late, and so do the invoices.

What stays with your people

Classifying a discrepancy and deciding how to bill it stays with warehouse and finance; the agent only surfaces the difference and the evidence for it.

What we built

  • A POD reconciliation agent that compares warehouse and carrier records and lists the differences on their own
  • An operations console for inventory, outbound and exceptions on one screen
  • Carrier and warehouse adapters, with reconciliation scripts that can be re-run

Systems involved

WMSCarrier portalsPostgreSQLEmail

Deliverables

  • POD reconciliation workflow and scripts
  • Operations console
  • Carrier and warehouse adapters
In progress · partial workflow live
Operations console demo ↗Warehouse workspace demo ↗

Adapters, some actions and the reconciliation scripts work; the full deployment is not finished. We do not quote a completion percentage.

Food service and at-home fulfilmentLoveHibachiAt-home hibachi service

HQ, stations and chefs working from the same facts.

  • Three sides: HQ, stations, chefs
  • Accounting and sales tax on Odoo 19
  • Tickets and e-signature closed inside the system

How it ran before

Orders arrive through several channels, shifts are arranged in group chats, and chef onboarding and contracts move as files back and forth. When something goes wrong, someone scrolls chat history to find out who did what, and nobody can say exactly who is allowed to change what.

What stays with your people

Assignment, complaint handling and contract terms stay with operations and management; the system records the process.

What we built

  • A fulfilment console where orders, shifts, stations and chef status move in one place
  • Odoo 19 accounting with US sales-tax integration
  • A built-in ticket system: the client files, we answer, and each fix ships with a replayable walkthrough
  • Chef onboarding with contract e-signature
  • Role permissions and an event log of actions

Systems involved

Odoo 19FirebaseStripeNext.js

Deliverables

  • Fulfilment console (web)
  • Odoo 19 accounting and tax modules
  • Ticket system with delivery walkthroughs
  • Deployment and environment pairing docs
In production
Fulfilment console (access required)

Core fulfilment and accounting run in production; some modules are still iterating in the development environment, and we say which is which.

Mobile and field serviceWASHGOMobile car wash and detailing

From the customer tapping "book" to the technician signing off on site.

  • Customer app and technician app both deployed
  • Scheduling reads shifts, location and travel time
  • Settlement, commission and journal entries land in Odoo 19

How it ran before

Bookings come in on the web and in a mini-program, dispatch happens in chat, job evidence sits in the technician’s camera roll, and settlement lives in spreadsheets. Each new city means teaching every region from scratch.

What stays with your people

Schedule drafts go out only after a dispatcher confirms them; compensation and complaints are decided by support and management.

What we built

  • A customer app for booking, rescheduling, reviews and after-service
  • A technician app for navigation, arrival, before/after photos and customer signature
  • A scheduling engine that plans the day within time windows, skills and capacity, with dispatcher override
  • Odoo 19 field-service tickets, Stripe collection and technician settlement

Systems involved

Odoo 19 Field ServiceStripeWeChatNext.js

Deliverables

  • Customer and technician apps
  • Scheduling engine and dispatch board
  • Odoo 19 field service and settlement configuration
  • Deployment records
Deployed demo
Customer app ↗Technician app ↗

Both apps are deployed and clickable; that is not the same as client sign-off or business results.

Cross-border commerce and brand sitesLovia · Cabinique · ITSVAJewellery · home and building materials · food marketplace

Catalogue, content, payments and back office should not be four separate projects.

  • Brand sites and a partner portal are live
  • Separate development, test and production environments
  • Catalogue, orders and after-service on Odoo

How it ran before

Product data is spread across supplier spreadsheets, image folders and a legacy site. Every launch means re-entering it, content and stock drift apart, and payments are reconciled against the back office by hand.

What stays with your people

Pricing, assortment and brand copy stay with the client; we make the data and the workflow line up.

What we built

  • Brand sites and a partner portal covering catalogue, content, checkout and after-service
  • Odoo integration for orders, subscriptions, delivery and after-service
  • Product data organisation and a launch workflow

Systems involved

OdooNext.jsStripeSupabase

Deliverables

  • Brand site and portal front ends
  • Odoo business modules and integrations
  • Multi-environment deployment and release process
Engineering work · build and deploy records

Sites and portals are live, with module sign-off confirmed project by project; Cabinique is at research and prototype stage.

Labels, rates and paymentsPointVault · YibaRating and labels · warehouse trucking plans

Rating, purchase and settlement, joined into one line.

  • Rate lookup wired to label purchase
  • Payments reconciled against the ERP
  • Trucking plans aggregated by destination warehouse

How it ran before

Rate lookup, label purchase and bookkeeping each use their own tool, with amounts and tracking numbers copied between them. Trucking plans are summed up by hand from several spreadsheets that do not agree on definitions.

What stays with your people

Carrier choice, rate negotiation and payment approval stay with operations and finance.

What we built

  • A rate-and-label workflow including payment and receipts
  • Order and settlement integration with the ERP
  • Warehouse plan sync, aggregated by destination to produce trucking reports

Systems involved

OdooCarrier APIsStripeSpreadsheets

Deliverables

  • Rating and label workflow
  • ERP integration and reconciliation
  • Trucking report generator
Engineering work · build and deploy records

Implementations and completion records exist; production scope is confirmed per project.

Education and professional servicesXinliStudy-abroad and admissions advisory

Keep the advisor’s judgement; hand the paperwork to the system.

  • Advisor workflow and platform plan
  • Proposal written, not yet contracted

How it ran before

Student documents, conversations and application progress sit in chats and docs, so advisors spend their time hunting for files and answering the same questions.

What stays with your people

School selection, essays and advice to families remain with the advisor and are explicitly out of automation scope.

What we built

  • An advisor AI workflow and platform proposal, with scope, phasing and acceptance criteria

Systems involved

—

Deliverables

  • Proposal overview and phased plan
Proposal stage

This is a draft proposal, not a delivered case. It is here to show how we start an engagement.

LIVE

Systems you can open right now

These are demo environments we host ourselves — open them and click around. The demo databases are shared, so the data may have been changed by someone else; for a real walkthrough we reset them first and give you baseline figures to check against. Client production systems need authorisation.

Customs brokerageCustoms operations consolecustoms-brokers-demo.biroot.comOpen demoOverseas warehousingWarehouse AI consoleallways-demo.biroot.comOpen demoOverseas warehousingWarehouse operations workspacewarehouse-ai.biroot.comOpen demoField serviceMobile car wash · customer appwashgo-client.biroot.comOpen demoField serviceMobile car wash · technician appwashgo-staff.biroot.comOpen demoTruckingDrayage dispatch tooltrucking-tool.ant.restAccess requiredFood fulfilmentFood service fulfilment consolelovehibachi-console-dev.biroot.comAccess required

TOOLING

The tooling we bring

Four layers, all answering the same question: how an agent does real work inside the systems you already have, under your rules.

WORKBOOK

Rules and playbooks

We write your trade’s judgement into playbooks an agent can execute and a person can read: what counts as an exception, who decides, how a special account is handled. Knowledge moves out of one head and into a file.

A new hire can follow it, and your veteran’s experience stays.

OPENCLI

System adapters

Plenty of critical systems have no API, only a web interface. Our adapters follow the same path a person takes — sign in, page through, fill the form, read the result — and when the site changes, we change the adapter.

No waiting for a vendor API, and no need to replace the system first.

CONNECTOR

Local execution connector

A client installed on the operator’s own machine that runs tasks with their existing sessions and network, and logs what it did. Steps that need a decision surface in front of them.

Gets around the "only works from the office machine" constraint.

Local execution does not by itself mean data stays local; data flows are designed per project and written into scope.

ODOO / ERP

Business systems and accounting

Orders, stock, work orders, invoices and payments need one authoritative record. We use Odoo 19 for that layer, and we connect to the ERP, QuickBooks or in-house system you already run.

What the agent does lands on real business objects and real books.

WORKSPACE

Team workspace

Web and mobile surfaces where people and agents meet: progress you can see, results you can review, and a way to take over a decision. Roles and permissions follow your org.

Work moves through the system instead of a group chat.

OPERATE

Deployment and long-run operation

We deploy into the agreed environment with versioning, rollback and status docs, then iterate on how it actually gets used. Client test, demo and production environments run on our own cluster.

Someone still owns it after handover — not a one-off project.

ENGAGEMENT

How we work together

Every step produces something you can review. Stop at any step if it is not working — no large contract up front.

01

Map one workflow

With the owner and the people doing the work, we map inputs, rules, exceptions and responsibilities, then pick the one workflow worth doing first.

Process map · scope and acceptance criteria

02

Build and connect

Rules become playbooks, agents get connected to your systems, and the points that need a human decision are marked explicitly.

Playbooks · agents and adapters

03

Verify on real work

We run it against real work in the agreed environment, compare with what your people produce, and close the gaps and edge cases.

Verification records · operating docs · training

04

Operate and extend

After launch we watch how it is used, fix what breaks and add the next workflow. Tickets, versions and status live in the system, not in private messages.

Support scope · the next workflow

What you get

The exact deliverables, code and IP ownership, and data handling are written out item by item in the contract and SOW, not left to boilerplate.

  • 01A workflow blueprint: process map, scope, acceptance criteria
  • 02Working agents and system adapters
  • 03A workspace your team uses (web / mobile)
  • 04Rules and operating playbooks
  • 05Deployment notes, versioning and rollback
  • 06Training and an agreed support scope

Where we come from

50+Projects worked on
12yBuilding and operating in North America
12yOdoo and Jira implementation
24hTeam coverage across time zones

Flexible to start

  • Start with a small contract and one workflow, then scale
  • Iterative delivery — something to look at every week
  • No long subscription required before we begin

The team

  • Strategy, engineering and go-to-market in one team
  • A partner works on your project — not a sales handoff
  • Coverage in both US Pacific and Asian working hours

What we know well

  • US–China logistics, customs brokerage, overseas warehousing
  • Odoo 19 implementation and custom modules
  • Connecting legacy systems that have no API

These are BiRoot’s own statements, not third-party certifications. Where clients are involved, the scope and current stage are stated in each case above.

Common questions

Do we have to replace our current systems?

Usually not. We first assess the interfaces, access paths and permissions you already have, and in most cases we start by connecting the existing workflow. Whether to replace a system depends on its real constraints and the scope we agree.

Can you connect systems with no API, like NetCHB or terminal portals?

Yes — this is a large part of what we do. Adapters follow the same path a person takes, and where necessary they run on the operator’s own machine with their existing session. Portal redesigns do break adapters, and keeping them working is part of the support scope.

How long until it is live?

It depends on workflow complexity, how ready your data and access are, third-party integrations and acceptance requirements. We define one workflow and agree a pilot scope before committing to a schedule. We do not quote a blanket delivery time.

How are data and sensitive actions handled?

At kickoff we write down data flows, which models may be used, access rights, which steps need human confirmation and what must be logged. Local execution does not automatically mean data stays local; each deployment is designed explicitly.

Who owns the code and deliverables?

Each item is agreed in the SOW: custom code, playbooks, platform components, third-party tools and ongoing services each have their own licensing and delivery terms. Exclusivity or source-code delivery can be negotiated.

How do we start, and how is it priced?

Bring one workflow you handle by hand over and over: which systems it touches, how often it runs, and where it jams. We assess it, then price discovery, implementation or ongoing service separately, with milestones and acceptance written in.

We are already a client — where do we see tickets and invoices?

In your client workspace: tickets, invoices, the applications and environments we run for you, and the state of your accounts and connections. The workspace opens up as the engagement grows, and we issue the accounts.

START HERE

Tell us one workflow you keep doing by hand

No need to know anything about agent architecture. Tell us who does this today, which systems it touches, how often it runs and where it jams. We read it properly before replying. Budget and timing can come later.

Or just write to us: [email protected]

Already a client?

Tickets, invoices, the applications and environments we run for you, and the state of your accounts and connections — all in your client workspace.

Open client workspace →