Start with a recurring customer question
Before listing features, listen to customers and the staff who support them. What do customers need to discover or complete, and how do they do it today? Repeated questions about job status, documents, or missing inputs can provide a starting point to investigate.
Select a customer group and one problem. A company ordering regularly from an agreed product range may need a different flow from one requesting a bespoke quotation every time. The B2B label alone does not define the service workflow.
The first release should complete one workflow
Record the chosen flow's starting point, decisions, and outcome. For job tracking, customers need to find their job, understand its state, and identify the next step. For a request flow, they need to submit it, add information, and receive a clear explanation of what follows.
Give each proposed element a reason linked to a decision or task. Include supplier-side work: who accepts requests, corrects data, and confirms completion? Without that, a portal may simply create another inbox to monitor.
Give every data item a source and owner
For status, deadlines, and documents, record who creates the information and which system is authoritative. Agree how it reaches the portal and what happens when updates are delayed. Customers should understand whether a deadline is confirmed or provisional.
Flag unverified integrations as open questions. Request sample data and investigate existing system capabilities before extensive screen design. If the first release uses manual updates, assign an owner and checking interval. Include that work when assessing portal operations.
- What does each displayed state mean?
- Who corrects an inaccurate value?
- When was information last updated?
- What appears when an input is missing?
- How is a proposal distinguished from a confirmed outcome?
A company account may involve several people
List cases involving multiple people from a customer company. A buyer may prepare a request, an engineer add an attachment, and a manager confirm the next step. Define accessible records and how each person is associated with the company.
Agree who handles adding colleagues, changing responsibility, and departures. Test someone representing multiple branches: which branch are they acting for, and where will their request belong? Resolve these questions before a company account becomes a single shared login.
Give exceptions a clear next step
Consider a missing job, an incorrect attachment, or a change to an already submitted request. Explain what customers can correct themselves and when staff take over. The receiving team needs context so customers do not repeat their explanation.
Record what happens after repeated submission or interrupted work. Until users see a confirmed result, they may retry the same action. Acceptance checks should cover agreed exceptions and resuming unfinished cases as well as the normal flow.
Evaluate the pilot through completed work
Decide what question the pilot must answer. Login counts are insufficient. In our model portal, the important outcome is whether customers found the missing input, supplied it correctly, and enabled staff to use it without re-entry.
Track cases returning to phone or email and why. Someone may encounter an unclear state, a missing document, or simply no reason to visit the portal. Treat these situations differently. Link findings to specific changes and decision owners.
- Core task completion and assistance needed.
- Time spent by customers and support staff.
- Unclear or inaccurate information.
- Cases handled outside the portal and their reasons.
- Operating work required to keep information current.
Choose the next phase from the evidence
After the pilot, decide what to keep, change, or defer. Successful use of one flow can inform a related need. Each new feature needs its own reason and dependencies rather than inclusion because another portal offers it.
For a DAVOND consultation, bring a recurring customer request, its current handling process, and required data sources. Together, we can review a useful first-release scope and the questions to investigate before design and development.