Bring the problem before the feature list
Hawk Lane approaches custom work as a solution discussion across the logistics operation. The starting point can be a dispatch bottleneck, a document delay, an accounting handoff or several disconnected processes. You do not need to arrive with a finished software specification.
Explain what your company is trying to achieve, what happens today and where the process breaks. Discovery can then assess whether the answer is an existing product, a configured workflow, an integration or separately scoped development. The standard TMS versus custom development comparison helps with that buying decision; this worksheet helps prepare the actual project conversation.
Three requests that make a concrete starting point
1. A dispatch board shaped around your lanes and rules
The operating problem might be assignments spread across spreadsheets, a whiteboard and WhatsApp, with no shared status. Describe which lanes matter, what a dispatcher needs to see, how assignment decisions are made and which conflicts should stop or warn a user.
An example requirement is: “Show the current assignment against each load and identify a conflicting assignment before the dispatcher confirms the change.” That is a discovery example, not a promise that a particular conflict rule is already configured. Define the actual rule and exceptions with your team.
2. A driver workflow for location and photo POD
The problem might be repeated location calls and billing waiting for delivery paperwork. If the project needs a driver app with live GPS and photo proof of delivery, specify when location should be shared, who should see it, which documents are needed and how the office accepts them.
Discuss driver permissions, privacy, device connectivity and what happens when a photo or update arrives late. A custom requirement does not establish continuous background tracking, automatic customer access or a feature included in every standard plan. Those behaviors need an explicit scope and appropriate disclosures.
3. Connections to the systems you already use
The problem might be entering the same information into the TMS, accounting software, ELD platform and a customer system. Name each provider and the exact record to exchange, such as an invoice, vehicle event or customer order. Specify which system owns the record and which direction the data should move.
List required access, fields, timing and what the office should do when a connection fails. Provider API access, regional availability, compatibility, charges and ongoing support must be assessed; naming a provider does not confirm an available integration.
Copy this discovery worksheet
Prepare short answers for the rows below. A blank or uncertain answer is a useful discovery question. Use masked examples rather than real customer, driver or payment records in an initial brief.
| Prompt | What to bring |
|---|---|
| Operating problem | Who is affected, what goes wrong and one recent example with sensitive details removed |
| Current workflow | Trigger, steps, people, tools and the point where work is delayed or repeated |
| Desired result | The observable change you want, without assuming a particular technical design |
| Users / permissions | Who views, edits, approves and receives information; regional or company boundaries |
| Records / documents | Relevant fields, sample layouts, source systems and known gaps |
| Connections | Provider names, record direction, required timing, API availability and failure owner |
| Exceptions | One missing-data case, one conflict and the person who should resolve each |
| First phase | The smallest useful workflow, essential requirements and items that can follow |
| Acceptance example | Given a sample input and user role, what should happen and what must wait for approval? |
| Delivery / support | Constraints, migration needs, hosting, ownership, training and support questions |
Turn a vague request into something the team can test
“Connect our accounting” leaves too many decisions open. A more useful brief says: “When an authorized user approves an invoice, prepare the agreed fields for our named accounting system; if the destination rejects it, the billing team needs to see the reason and decide the next step.”
Then supply a masked invoice, the destination product/version, required fields and an example rejection. This is a requirements example for discussion, not a claim that Hawk Lane already supports every accounting product or every invoice field. For the existing standard path, review QuickBooks TMS integration separately.
Choose a first phase around a complete task
Prioritize an operating task that a real user can complete, including its exceptions and handoff. Separate essential rules from conveniences. For example, define the assignment decision and shared status before adding every report someone might eventually want.
Also discuss how the team will migrate records, learn the workflow and handle support. Cost, delivery phases, hosting and ownership are agreed through the project proposal and contract. This checklist is a starting point for custom TMS software development, not a fixed feature package or estimate.
Questions before discovery
Can we discuss a problem outside these three examples?
Yes. Bring the wider logistics problem, including the people and tools involved. Hawk Lane can assess the connected workflow and discuss a practical solution; feasibility and deliverables are established during discovery.
Do we need to choose the technology first?
No. Begin with the operating requirements, users, existing systems and constraints. The technical approach follows that discussion.
Does this replace a written project scope?
No. The brief provides input for discovery. The approved proposal defines deliverables, integrations, responsibilities, commercial terms and acceptance criteria.
Discuss your operating problem
Discuss your workflow and confirm the right product, configuration or project scope with Hawk Lane.