Delegate to subcontractors without losing visibility or control.

Using subcontracted capacity is a normal part of running a bulk haulage operation — particularly for operators managing overflow volumes, specialist equipment requirements, or geographic coverage beyond their owned fleet. The commercial relationship with subs is well understood. The operational coordination is where it gets difficult.

When you send a job to a subcontractor by phone or WhatsApp, you have transferred the job and lost the thread at the same time. The sub might confirm verbally. They might reply “on it” in a WhatsApp message. They start the job. At some point during the day, your client calls to ask where their delivery is. You call the sub. The sub says they will check with their driver. You wait. You call the client back with second-hand information that is already twenty minutes old.

This is not a problem of subcontractors being unreliable. It is a problem of structure: the job left your system when it left your control. There is no mechanism by which status can flow back to you without a phone call. HaulageOps creates that mechanism — a dedicated portal for the subcontractor that is connected to your dispatch board, so delegation and visibility exist at the same time.

• Job sent by phone = job exists only in someone's memory
• No confirmation workflow = no certainty the sub has accepted
• No status channel = no update without calling them
• No POD from sub = invoice evidence relies on paper dockets arriving at your office
• Client query = phone chain with no guaranteed answer

One of the operational risks of connecting external parties to a shared system is data leakage — a subcontractor seeing your client's full rate card, or a client seeing your subcontractor relationships. HaulageOps uses role-based access control (RBAC) and multi-tenant architecture to prevent this by design.

What the subcontractor sees in their portal

• Only the jobs delegated to them — not your other clients' jobs
• Job details: pickup and delivery address, material, scheduled time
• Mapbox map showing job locations for navigation context
• Their own job history and status records
• Their own pay rate for each job — not your client charge rate

What the subcontractor does NOT see

• Your client's name or contact details beyond what the job requires
• Your client charge rate — they see only their own pay rate
• Your margin on the job
• Other subcontractors you work with
• Your owned fleet details, other client accounts, or your billing records

Your client's portal is equally scoped. They see their own jobs, their own POD, their own invoices, and their own rate cards. They do not see your subcontractor relationships or the fact that a particular job was fulfilled by a sub rather than your own fleet — unless your operational arrangement requires that disclosure.

When you use a subcontractor, you are managing two commercial relationships simultaneously: the rate you charge your client for the job, and the rate you pay the sub to execute it. The difference is your margin on that job. In most haulage operations, these two numbers live in different places — the client rate in one spreadsheet, the sub invoice in another — and the margin calculation happens once a month, by hand, after the fact.

In HaulageOps, both rates are attached to the job at dispatch. The client charge rate comes from the client's rate card — the same rate card that drives the invoice. The subcontractor pay rate is configured against the sub's record and applies when the job is delegated. Both rates sit on the same job record.

This means:

• The client invoice is generated from the client charge rate — correctly, automatically
• The sub's cost is visible against the job before and after delivery
• Job-level margin is visible in reporting without a manual reconciliation exercise
• The sub does not see your client charge rate — they see only their own pay rate
• Your client does not see your sub arrangements or your margin