A working system.
Built with your team.
Bring a process that takes too much effort to run. We map it with the people doing the work, agree what to build, and test it together before it takes on real responsibility. Here is what each side contributes and what you take away.
How a Spark engagement actually runs.
You bring a process owner, representative examples and access to the relevant systems. We bring implementation and documentation. The sequence below is a guide; scope, timing and responsibilities are agreed before a build starts.
Choose the problem worth solving.
Your team walks us through the real process, including the spreadsheets, workarounds and exceptions. We map the systems involved and define what a useful first result would look like.
- Map the current workflow and its owner
- Identify data sources and access requirements
- Agree how to measure a useful result
You choose whether to proceed. The diagnostic does not commit you to implementation.
- A Spark Map of the current setup
- A ranked backlog and a scoped build proposal
Build a first working version.
We implement the agreed workflow in your repositories and infrastructure. Your process owner reviews working versions and helps resolve the business rules that software cannot decide for you.
- Build the logic, interface and integrations
- Keep code and configuration versioned
- Set permissions and approval boundaries
You review the workflow and its permissions before we connect it to consequential actions.
- A working version your team can try
- Documented rules and access boundaries
Prove it on the work you actually do.
Your team brings representative cases, including the awkward ones. We compare results with the agreed criteria, test failures and refine the interface before asking people to rely on it.
- Test normal cases, exceptions and failures
- Verify approvals and recovery paths
- Resolve issues with the process owner
You decide when the workflow is ready for real use and how much autonomy it gets.
- Reviewable test results and known limits
- An agreed rollout and fallback plan
Operate without us.
We walk your team through running, changing and recovering the system. Accounts, code and documentation stay with your company. Any ongoing support is agreed separately, not required to keep access to what we built.
- Walk through operations and recovery
- Verify access to repos, infrastructure and secrets
- Document maintenance and extension paths
Your designated owner confirms they can access and operate the system.
- Code, configuration and operating runbooks
- A named owner and a prioritized next-step list
Looking for the thinking behind these choices? Read our principles →
What should your company
stop doing by hand?
Bring one process that is slow, fragile or hard to change. We will look at what a useful first version could do.
Scope, cost and operating responsibilities are agreed before a build starts.