Start with a specific moment
“We need a platform” is a direction, but it is not yet a brief. Start with a moment you can describe: a colleague copies information between two systems; a customer cannot complete a task without calling; a new service depends on a spreadsheet only one person understands. A concrete example makes it easier to identify what the software needs to change.
Follow the information
Write down where the information comes from, who needs it and what happens next. Include the awkward steps. Exports, forwarded messages and manual checks often explain the real shape of the process better than the official workflow does. Existing tools belong on this map too. A new platform may need to connect them rather than replace them.
Name the people involved
The person using a customer portal is not the only user. Someone may need to approve requests, correct information, answer questions or manage access. Give those people a place in the brief. Their needs influence the platform just as much as the customer-facing screens.
Define the first useful release
Describe the smallest complete journey that would make a difference. It needs a beginning, a useful result and a way to handle the situations that do not go to plan. A small release is not simply a longer feature list with items removed; it should still help someone finish a real task.
Bring the unanswered questions
A brief does not need to pretend every decision has been made. Include what you know, what you suspect and what you need to learn. That creates a better starting point for discovery than a list of features with no context.
See the work behind the thinking.
The PetStore Direct platforms show how customer conversations connect to existing commerce and support systems.
Explore the two PetStore platforms
