01 / discovery
Observe one recurring job.
We map the trigger, people, current systems, authoritative sources, rekeying, approvals and common exceptions. The business owner and domain reviewer help identify what “done” actually means.
How it works
From the first conversation to ongoing support.
Threadworks is designed around implementation, staff practice and continuing ownership. A tool installed without a useful task, trained users and a failure path is not an accepted workflow.
02 / implementation package
Configure and test the agreed workflow.
We configure the pilot around approved information and agreed system connections, then test normal work and common exceptions. The handoff includes operating instructions, test results and clear limits on what the workflow can change.
03 / hands-on training
Have intended users do the work.
Staff use representative cases, inspect sources, correct an output and practice an exception or escalation. Watching a demonstration is not treated as adoption.
04 / rollout
Release in a controlled scope.
Initial use is measured against the agreed workflow. The team records misses, false flags and correction effort alongside useful outputs. Any broader automation or additional system access is a separate decision.
05 / ownership and support
Keep the operating model current.
Management can cover instruction changes, source or access review, failure analysis, staff support and provider-usage discussion. Support scope and response expectations are agreed before work begins.
06 / exit or change
Keep the business in control.
The business retains the decisions about its workflow. If scope ends or changes, the transition can include agreed documentation, workflow materials and a clear handoff of what has been maintained.
Automation follows evidence. A prepared draft, a review queue, a limited write-back and an autonomous action are different levels of scope. The least autonomous method that works is usually the right starting point.
What you receive
The written scope sets out the work and handoff before implementation starts. Depending on the service, the project package includes:
- A clear scope and cost breakdown. The task, connected systems, customer responsibilities and acceptance criteria, with implementation, ongoing management, and third-party software and usage charges separated.
- The agreed working setup or outputs. A configured assistant, workflow, reporting process or content package in the agreed environment, with ownership and software usage rights recorded.
- A test and rollout record. Representative cases, identified limitations, corrected failures and a decision about what is ready for live use. A good demonstration alone is not acceptance.
- Instructions and hands-on training. How to use the workflow, check an answer, correct a mistake, handle an exception and pause the process.
- An access and data-handling record. Accounts, permissions, providers, approved actions and retention arrangements, following the security and access plan.
- Support and offboarding arrangements. Named responsibilities, agreed support hours and response expectations, included changes, recurring costs and the materials and access changes required when the service ends.
The scope identifies which items apply to your project. Additional systems, channels, custom features or support commitments require a separate agreement.
Prove one workflow before expanding it
Start with approved sample information and a narrow task. Confirm the tools, access and licensing, test the result with its intended users, then decide whether to proceed. A connection that has not been tested in the customer's environment is not treated as ready.
Read-only work, drafts for review and approved system changes are separate release decisions. Automated follow-up, appointment booking and publishing need their own tests and authorization. Phone answering and high-risk decisions are not part of the standard starting scope.