Imogen Labs
Start a project

A logistics website that works

From first visit to draft quote.

Client work

A delivery business needs more than a page with a phone number. We built a logistics client a service website, phone-friendly publishing and a quote-request flow connected to its back office.

Inside A logistics website that works
  1. DiscoverFind the service and coverage information.
  2. DescribeSupply route, load, timing and jobsite details.
  3. RecordCreate a client and draft quote server-side.
  4. RespondDispatch reviews the request and sets the price.

The problem

The business needed to explain its services and coverage clearly to people arranging time-sensitive deliveries. Those visitors are often on a phone at a jobsite. The website had to make the service understandable and collect enough detail for dispatch to respond usefully.

Publishing was the other practical requirement. A site becomes expensive to maintain when announcing a new service area needs a developer. The first content approach expected repository edits. We replaced it with a proper editor the business could use from a phone.

Who it’s for

A regional jobsite-delivery business serving contractors, distributors and construction teams.

What we built

We built a multi-page service website with dedicated service pages, coverage information, FAQs, contact routes and a blog. A custom map draws Georgia’s 159 counties and highlights service zones without depending on an embedded map. Business facts and service content have shared sources so contact details stay consistent.

The content system is separate from the marketing site. Authors write in a visual editor, publish, and the site reads published posts through an API. Dates and page addresses fill themselves in. Technical fields stay out of the way, account management is hidden from authors and touch-friendly controls support publishing away from a desk.

The quote form captures the route, load, timing, jobsite requirements and contact details. It can include additional stops, handling flags, access notes, insurance requirements and supporting images or PDFs. Those details are organised around what dispatch needs to know rather than a generic contact message.

How it works

A submitted request goes to a server-side endpoint. It validates required fields, checks uploads and creates a client record plus a draft quote in the invoicing system. Route and load details become readable notes. Pricing remains a human decision; the form does not invent a delivery price.

The integration keeps the back-office credential on the server. A request limit and hidden bot field reduce unwanted submissions. Up to eight supporting files can be accepted, with a documented limit of 15 MB per file. If an attachment upload fails after the draft exists, the lead remains recorded for follow-up.

The static marketing pages and live publishing service have separate responsibilities. This keeps routine page delivery simple while letting the business publish without rebuilding the site. The same principle applies to quoting: the public form gathers the work, and the existing back office receives a structured draft.

What was hard

The useful work was in the handoffs. The author needed a familiar editor rather than a developer console. Dispatch needed structured job details rather than an inbox full of incomplete messages. A customer needed a clear error and a fallback contact path if submission failed.

A later business rebrand reached beyond visible page headings into contact routing, metadata, the sitemap and operational documentation. The recorded pass brought the sitemap to 35 URLs and removed stale references. Shared business facts meant a corrected contact address flowed through the pages that used it, instead of requiring a separate repair in each component.

Have a similar problem?

Let’s build
what comes next.

Start a project