Your work, before the software.
Spreadsheets and tools have accumulated over time. We look at how your team works to identify what internal software should simplify before deciding what to build.
A specific use.
Scattered tasks
Follow a case through files, conversations and approvals.
Different user roles
Clarify who can view, change and approve information.
Existing systems
Identify the data and connections that need to remain.
What you get from the brief.
A map of the workflow
Roles, data and handovers that create repeated entry or block progress.
A single diagram of the process end to end, with the interview notes it was drawn from in a folder you keep.
A working journey prototype
Screens for the priority process, reviewed with the people who will use them.
Clickable screens covering one case from intake to approval, plus the recording of the session where your team tried them.
Usable requirements
Initial scope, access rules, dependencies and acceptance criteria.
A numbered specification, one acceptance criterion per line, written so any development team can quote against it.
How long it takes.
Three to five weeks, depending on how many roles touch the process and how fast the interviews can be booked. The workflow diagram lands once the interviews are done, usually in week two.
What we need from you.
Time with the people who do the work
Four to six interviews of forty-five minutes, with the people who run the process every day. Their workarounds are the real requirements, and managers rarely know them.
One case we can follow from end to end
A recent file with its emails, attachments and approvals, exactly as it happened, anonymised if it has to be. A tidy example hides the exceptions that cost the most to build.
A decision on the tools already in place
Which systems stay, and who holds their licences. Migration cost is settled at this point, well before anyone writes code.