Client responsibilities
Active participation makes the work usable.
- Process owner
- User access
- Representative data
- System access
- Clear business rules
- Timely feedback
- Testing participation
- Final approval
- Adoption ownership
- Legal and data approvals
Process and delivery
A controlled path from an operational problem to a usable system.
A project should begin by confirming the workflow, the people involved, the available information, the risk of incorrect actions, and a practical way to judge success. Scope, responsibilities, testing, and approvals stay visible from the beginning.
01
Workflow
02
Ownership
03
Controls
04
Testing
05
Next actions
Delivery process
Validation at every important decision.
Each stage has a defined purpose, a named client role, a practical deliverable, and a decision gate.
01Suitability discussion
Confirm whether the problem is specific, repeated, accessible, and important enough to investigate.
What Glitch does
- Understands the workflow at a high level
- Reviews impact, users, tools, urgency, and constraints
- Assesses whether automation is likely to be practical
What the client does
- Brings one real workflow
- Includes someone who understands or owns the process
- Shares the expected improvement
Deliverable
Suitability note or recommended next step.
Decision gate
Is the problem specific, repeated, accessible, and important enough to investigate?
Typical risks
- Technology request without a business problem
- No clear process owner
- Requirement is too broad
ApprovalAgreement on the workflow to investigate and people required.
02Workflow discovery
Understand how the work actually happens today.
What Glitch does
- Interviews users and reviews sample records
- Observes handoffs, approvals, systems, and reporting needs
- Identifies standard paths, exceptions, and workarounds
What the client does
- Provides representative users
- Shares trackers, documents, and examples
- Confirms current pain points
Deliverable
Current workflow summary and issue list.
Decision gate
Is the process understood well enough to separate process, policy, data, training, and software problems?
Typical risks
- Only management explains the process
- Edge cases remain hidden
- Examples are not representative
ApprovalThe process owner confirms the current workflow summary.
03Current process mapping
Create one agreed view of how the process currently works.
What Glitch does
- Documents steps, owners, inputs, and outputs
- Identifies waits, decisions, duplicate handling, and failure paths
- Maps manual follow-ups
What the client does
- Validates terminology and ownership
- Confirms source systems and exceptional cases
- Resolves conflicting process descriptions
Deliverable
Approved current process map and responsibility outline.
Decision gate
Which steps should be simplified, removed, standardised, integrated, assisted, or kept manual?
Typical risks
- Automating unnecessary steps
- No authoritative data source
- Conflicting role ownership
ApprovalThe named owner approves the process boundary.
04Baseline and success criteria
Define how the project will be judged.
What Glitch does
- Proposes a practical baseline
- Defines success criteria and measurement sources
- Separates targets from measured outcomes
What the client does
- Supplies available historic or observational data
- Agrees how success will be interpreted
- Confirms what matters most
Deliverable
Baseline, success criteria, measurement source, and limitations.
Decision gate
Can the expected improvement be assessed without inventing precision?
Typical risks
- No usable baseline
- Success is defined differently by teams
- Targets are treated as guarantees
ApprovalSuccess criteria and outcome labels are agreed.
05Scope and proposal
Define exactly what is included, excluded, required, and approved.
What Glitch does
- Defines workflows, users, integrations, assumptions, and exclusions
- Sets the timeline approach, responsibilities, ownership, and support
- Defines change control and commercial terms
What the client does
- Reviews scope with operational and technical stakeholders
- Reviews commercial, legal, and data requirements
- Confirms decision makers and internal responsibilities
Deliverable
Written proposal and statement of work.
Decision gate
Are boundaries, responsibilities, risks, and acceptance conditions clear enough to commit?
Typical risks
- Hidden dependencies
- Vague acceptance criteria
- Major requirements left undocumented
ApprovalCommercial and scope approval.
06Solution design
Design the future workflow before the full build begins.
What Glitch does
- Defines data, roles, permissions, interface, and rules
- Designs integrations, alerts, exception handling, and testing
- Sets the build priorities
What the client does
- Confirms business rules, permissions, and source ownership
- Confirms user journeys and irreversible actions
- Confirms approval requirements
Deliverable
Solution design, interface outline, field definition, and test plan.
Decision gate
Does the design reflect the agreed process, users, and controls?
Typical risks
- Features added before core workflow validation
- Unclear permissions
- Exceptions left undefined
ApprovalDesign and build priorities are approved.
07Pilot build
Build the agreed core workflow in manageable stages.
What Glitch does
- Builds in reviewable increments
- Records assumptions, issues, and dependencies
- Demonstrates progress against the approved design
What the client does
- Provides access, examples, and decisions
- Gives consolidated feedback
- Joins agreed review sessions
Deliverable
Working pilot and build notes.
Decision gate
Does the pilot execute the core use case with representative data?
Typical risks
- Delayed access
- Process changes during build
- Informal new requirements
ApprovalPilot approved for formal testing.
08Testing and user acceptance
Confirm that the system works safely and correctly for the agreed scope.
What Glitch does
- Tests normal, boundary, failure, permission, and recovery cases
- Records and fixes agreed defects
- Supports user acceptance testing
What the client does
- Runs representative scenarios with real users
- Confirms business accuracy
- Accepts or rejects against agreed criteria
Deliverable
Test record, UAT log, defect status, and acceptance decision.
Decision gate
Is the workflow safe and usable enough for the agreed launch scope?
Typical risks
- Happy-path-only testing
- Users do not participate
- Change requests treated as defects
ApprovalWritten UAT acceptance or agreed conditional launch.
09Training and launch
Prepare users, access, data, documentation, and support before go-live.
What Glitch does
- Prepares the production environment and launch checks
- Prepares user guidance, monitoring, and issue reporting
- Prepares handover materials
What the client does
- Confirms users, access, and process ownership
- Communicates the change internally
- Supports adoption and retires the old method where appropriate
Deliverable
Launched system, operating guide, access record, handover package, and support route.
Decision gate
Are users, data, responsibilities, and fallback arrangements ready?
Typical risks
- Parallel systems cause confusion
- Incorrect permissions
- No internal owner
ApprovalLaunch authorisation.
10Support, measurement, and improvement
Stabilise the system, review adoption, and decide what happens next.
What Glitch does
- Provides agreed support and reviews failures
- Reviews adoption and helps measure outcomes
- Suggests priorities and scopes material enhancements separately
What the client does
- Reports issues with context
- Maintains process ownership and user discipline
- Provides measurement data and approves expansion work
Deliverable
Support record, measurement review, and prioritised improvement options.
Decision gate
Should the system be maintained, improved, expanded, or stopped?
Typical risks
- Scope expansion through support
- No adoption owner
- Outcomes assessed too early
ApprovalSeparate approval for material enhancements or expansion.
Delivery principle
We build in small stages, test early, and do not move forward without validation.
The client remains involved in every important decision. The process is designed to make assumptions, responsibilities, approvals, and risks visible before they become delivery problems.
Focused pilots may commonly take approximately three to six weeks after scope, system access, representative data, and client responsibilities are confirmed. This is guidance, not a universal promise.
What affects timeline
Timeline depends on more than development effort.
- Data quality
- Integration access
- Number of workflows
- Approval delays
- Changing requirements
- Security review
- User availability
- Migration volume
- Third-party dependencies
- Custom interface requirements
Testing and acceptance
Testing should reflect real operating conditions.
- Normal cases
- Boundary cases
- Exceptions
- Permissions
- Failure handling
- Recovery
- User acceptance testing
- Defect management
- Launch approval
Launch and post-launch support
Launch is the beginning of operational use, not the end of delivery.
Documentation
User guides, process notes, access information, known limitations, support route, and handover records.
Training
Role-based training, user walkthroughs, process owner training, admin guidance, and recorded training where agreed.
Monitoring
System health checks, failure alerts, usage review, update monitoring, and provider dependency review.
Issue handling
Defined reporting channel, context requirements, priority rules, response expectations, and escalation route.
Handover
Account ownership, agreed code or configuration, documentation, data ownership, hosting information, and admin access.
Future improvements
New features, wider rollout, additional departments, integrations, and material workflow changes are scoped separately.
Proposal clarity
Every proposal should make the operational boundaries clear.
- What Glitch will do
- What the client must provide
- What is included and excluded
- Systems and assumptions involved
- How testing and acceptance work
- Ownership and support transferred
- What changes cost extra
- What could affect the timeline
Start with the current workflow
Bring the users, systems, and biggest bottleneck.
Share how the process works today, where it slows down, which people and systems are involved, and what a useful improvement would look like. Glitch will first assess whether the workflow is suitable before recommending a project.