B2B order management application: roles and billing

A B2B order management application must, above all, make clear who does what. The client raises an order and pays. The manager assigns people and keeps track of billing, and the employee does the job and records how it went. Permissions, order statuses and the way the bill is calculated all follow from this split.

Service Quotes is our example: an application we built for a service company that works for business clients under contract. The case study lists its features. The design decisions below apply to every system of this kind.

What roles does a B2B order system need?

Service Quotes has three account types, each with different permissions:

Role	What it does in the system	What it cannot see or change
Client	Raises an order for a service at a given address, reviews its orders, bills and payments, pays online	Other clients’ orders, employee data, company settings
Employee	Carries out the orders the manager assigned, records the job: materials, quantity, price, time and the rate for the type of work	Account and client management, the list of bills and payments
Manager	Manages accounts, employees, their specialisms and clients, assigns employees to orders, reviews bills and payments	No restrictions (full access within the company)

At the design stage, the first question is whether roles are enough or whether permissions need to be set for each person individually. With three clearly different user groups, roles are easier to understand and test. They are also easier to explain to the client. Per-person permissions become worth considering only when one role starts to have exceptions, for example a manager who should not see payments.

The second question is whether a B2B client is one person or a company with several users. If several people on the client’s side raise orders, you have to decide whether they see each other’s orders. You also have to decide who on the client’s side may pay. Make this decision before building the database, because changing it later touches almost every screen.

How do you assign staff to orders?

In Service Quotes, the manager reads the order description and assigns employees with the required specialisms. Specialisms are a separate list that the manager maintains.

This approach has two advantages. First, the manager does not have to remember who holds which qualifications, because the system shows only matching people. Second, the specialism list can later feed reports, for example on which services are ordered most often.

In Service Quotes, the manager makes the assignment decision. Automatic assignment sounds attractive, but it needs data that is usually missing at the start: staff availability, travel time, client priorities. Start with manual assignment, with the system suggesting matching staff, and add automation once you know the rules the manager actually follows.

How does the system calculate the bill?

In Service Quotes, the bill is produced only after the order is completed. During the job, the employee records the materials used, their quantity and price in the system. The employee also records the working time and the hourly rate for the specific type of work. When the order is complete, the system adds up the labour and material costs and produces an itemised bill for the client. The client pays it online, and the payment closes the process.

This model suits services where the scope of work only becomes clear on site. The billing rules (rates for each type of work) are agreed in advance in the contract. The client does not approve a quote before each order; they receive a bill in line with the contract.

When designing the bill, you need to answer a few questions:

• Where do the rates come from? Does the employee type them in, pick them from a price list, or does each B2B client have its own price list?
• Who can correct the line items? An employee’s mistake in the quantity of material should not reach the client unchecked.
• What happens when the price of a material changes? A bill issued earlier must show the price on the day of the job, even if the price list has since changed. Store the price on the bill line itself; a reference to the price list is not enough.
• What does the bill look like for the client? A B2B client usually passes it on (to accounts, to a manager), so it must be readable without signing in to the system.

Order statuses

Order statuses are an agreement between roles. Each status says who is responsible for the next step. A sample set for a process like the one in Service Quotes:

Status	Who is responsible for the next step
Raised	Manager: reads the description and assigns employees
Assigned	Employee: travels to the given address and starts work
In progress	Employee: records materials and working time
Billed	Client: reviews the bill and pays
Paid	Nobody: the order is closed

Record every status change with its date and author. In a dispute with a B2B client, the order history (“who changed what and when”) often matters more than the final state.

Online payments in a B2B application

Service Quotes clients pay the bill online, and the list of payments is visible to the client and the manager. With payments in a B2B system, a few things have to be agreed with the company’s accounts team. Which document is used for settlement: the bill, an invoice or both? How do you mark a partial payment or a refund? Should a payment change the order status automatically?

The status should change only once the payment operator confirms the payment. The client clicking a button is not enough. Our article on Stripe subscriptions in a SaaS application covers payments and subscriptions in more detail, using the Offer Exchange platform as an example.

The technology behind Service Quotes

The application runs on Next.js and React with TypeScript for the interface, .NET Core on the server and a PostgreSQL database. We used the same stack, with Tailwind CSS and Docker, in the Offer Exchange platform.

The interface is separate from the API (application programming interface), the layer through which the interface talks to the server. This has a practical benefit: the billing logic sits in one module on the server, so another interface, for example an app for field staff, does not require rewriting it.

When a custom order system makes sense

Off-the-shelf order management programs work well for standard processes. A system of your own makes sense when billing follows individual B2B contracts, or when the client is meant to raise orders and pay in the same application. A third reason is assignment based on specialisms that an off-the-shelf program does not support. Our article on custom vs off-the-shelf software gives a broader comparison, and our custom web applications page shows how we build such systems.

If your company handles orders by email and spreadsheet, start with our guide to preparing for a custom software project. Then write to us, and we will help you settle the roles, statuses and billing rules before the first screen is built.