Introducing SlashFlow
Work should move. Not wait. How an internal workspace at SlashTech became the starting point for a product connecting clients, projects, time and billing.
Toward yours.
Inside SlashTechA real need.Coordinating our own client work.
- An internal workspaceBuilt. Used. Refined.
Learning through everyday use.
SlashFlowA wider purpose.In development for other teams.
A project can be ready to move while the people responsible are still piecing together what happens next. What did we agree with the client? Where is the current document? What has been delivered, and what is ready to bill?
Each question sounds small. Together, they describe the effort of keeping work connected.
We believe people should be able to put more of their attention into the work they are trusted to do. The systems around them should help them understand where things stand and carry that work forward.
That belief is behind SlashFlow, a connected workspace we are developing for consultancies, agencies and service teams. Its starting point was a need inside our own operation.
It started inside SlashTech
SlashTech needed a way to coordinate engagements, documents, delivery and billing. These were connected parts of the same work: what had been agreed, what needed to happen, the records around it and the commercial details that followed.
We built an internal workspace around that need. It became the system behind SlashTech’s Client Hub, coordinating our work behind the client-facing view.
Then we used it, and kept improving it.
Working inside a system you are building gives you a particular kind of feedback. You have to live with the decisions you made. The structure that seemed clear while designing it has to make sense during a working day. Each improvement has somewhere real to be tested.
That experience gave us a foundation to build from, and a question worth pursuing: how could this become useful to teams beyond our own?
Building for other teams
Developing an internal tool into a product means taking responsibility for a wider set of needs. Other teams have their own ways of working, their own constraints and their own expectations. Something that makes sense to its builders has to become understandable to someone meeting it for the first time.
That is the work now taking shape as SlashFlow.
We are developing it to bring clients, projects, time and billing together in a connected workspace. Those parts belong to one continuous piece of work. A client relationship leads to a project. Delivering the project takes time. Billing should make sense in the context of what was agreed and delivered.
The aim is to make those connections easier to follow, so people can spend less effort reconstructing the story of a project before deciding what to do next.
Our own experience gives us somewhere concrete to begin. Learning how other teams work will help shape what comes next.
Why it belongs in Slash Group
At Slash Group, we believe building something successful and building something that matters should go together. That asks us to begin with a problem we can understand, build something useful and keep learning from what happens in practice.
SlashFlow is a concrete example of that approach. An operational need inside SlashTech led to a workspace. Building and using it developed knowledge and capability that we can now carry into a venture with a wider purpose.
There is still work to do. The standard is whether SlashFlow becomes useful in the working lives of the people it is being built for. That is what development has to earn.
An introduction, with more to build
SlashFlow is in development. We are introducing it through an early-access waitlist, with access offered progressively as the product takes shape. Joining registers interest; it does not provide immediate access.
For consultancies, agencies and service teams, this is an invitation to follow what we are building from the beginning.
Work should move. Not wait.