{"teams":[{"team":"Software Development","owner":[{"name":"TBD","email":null}],"members":"Dev Pandya, Mukesh W., Deep Gandhi...","mission":"Build and ship what was agreed for the week, into production, on a one-week cycle.","serves":"Both – client systems and the internal Twym product estate","engage":"TBD","leadTime":"Next weekly cycle","capacity":"TBD","maturity":"2 - Repeatable","interviewStatus":"","confirmedOn":"","sourceFile":"Confluence page 473432066","services":[{"id":"DEV-01","name":"Build product features","owner":[{"name":"TBD","email":null}],"purpose":"Turn an agreed ticket into working software inside the weekly window.","description":"Implements features on the Twym product estate – TwymWork, TwymMind, TwymEdge and the rest – from tickets created out of the weekly scope agreement. People are assigned to stories in Jira and log time through Tempo. No estimates are produced.","inScope":"Feature implementation; unit-level testing by the developer; code review; in-code documentation","outOfScope":"Client-specific application build (DEV-02); deciding what to build (PRD-04); functional test execution (QA-03); deployment to production (DEV-06)","trigger":"A ticket enters the sprint out of the weekly scope agreement","inputs":"Ticket with enough definition to build; designs where the feature is user-facing; architecture position where it touches integration","keyActivities":["Pick up the assigned story.","Implement against the specification and standards.","Self-test.","Submit for review.","Log time in Tempo."],"outputs":"Working feature in the repository; reviewed code; in-code documentation","definitionOfDone":"Reviewed, merged, and demonstrably doing what the ticket asked","consumes":"BA-02 – Write user stories and acceptance criteria\nBA-05 – Analyse data and define reporting\nPRD-03 – Specify a feature for build\nPRD-04 – Agree the weekly delivery scope\nTL-01 – Define and own the solution architecture\nTL-02 – Set and enforce technical standards\nTL-03 – Review feasibility of designs and requirements\nTL-06 – Onboard a developer technically\nUX-01 – Produce product screen designs\nUX-02 – Build and maintain the design system\nUX-04 – Define and validate UX flows","feeds":"DEV-06 – Release to production\nQA-03 – Functional Validation\nQA-04 – API / Backend Validation\nQA-13 – AI Product / Software QA\nTL-05 – Manage technical risk and technical debt\nUX-03 – Run design QA on built interfaces","tools":"Jira, Tempo, Git-based repositories. Github Actions, Github self hosted runners and GitLab for mobile team sometimes for CI/CD.","reusableAssets":"Components and modules with reuse potential across the product estate – the judgement Sébastien currently makes informally in the weekly meeting","typicalEffort":"TBD","typicalDuration":"One-week delivery window","deliveryModel":"Internal, with sell-in to clients","pricingUnit":"TBD","contribution":"The entire product estate","maturity":"2 - Repeatable","gapsAndRisks":"No estimates, so a week's scope is agreed on judgement alone","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"DEV-02","name":"Build client-specific applications","owner":[{"name":"TBD","email":null}],"purpose":"Deliver software built to a client's requirements, as a contracted IT firm rather than as a product vendor.","description":"Builds systems specified by the client.","inScope":"Requirements-driven build for a named client; client-specific integration; RBAC and configuration; production release into the client context","outOfScope":"Product feature build (DEV-01); requirement definition, which the client supplies; the IP and reuse position (LEG-03, AEX-05)","trigger":"A contracted client development scope","inputs":"Client-supplied requirements and scope; environment and tenancy decision; access to the client estate where needed","keyActivities":["Take requirements and scope from the client.","Build against them in the weekly cycle.","Integrate with the client's systems.","Release to production.","Support through early life."],"outputs":"Working client system in production; RBAC matrix; architecture and data flow diagrams; notification configuration","definitionOfDone":"In production, used by the client's users, with the documentation set handed over","consumes":"BA-01 – Elicit and document requirements\nBA-02 – Write user stories and acceptance criteria\nBA-03 – Produce functional specifications\nDEV-03 – Integrate third-party and client systems\nTL-01 – Define and own the solution architecture\nTL-02 – Set and enforce technical standards\nTL-04 – Own environments and the deployment approach","feeds":"AEX-01 – Identify reusable assets in delivered work\nAEX-05 – Assess productisation and the IP position\nDEV-05 – Produce technical documentation\nDEV-06 – Release to production\nQA-03 – Functional Validation\nExternal: OPS-02 – Run service management operations (Operations, outside this catalogue set)\nExternal: ACC-01 – Invoice clients (Accounting, outside this catalogue set)","tools":"Jira, Tempo, Microsoft and Azure tenancy, AWS, SharePoint, Excel","reusableAssets":"TBD","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable","pricingUnit":"TBD","contribution":"The custom development offer, and the route by which product ideas reach a real client","maturity":"2 - Repeatable","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"DEV-03","name":"Integrate third-party and client systems","owner":[{"name":"TBD","email":null}],"purpose":"Connect what Twym builds to the systems it has to live with.","description":"Builds and maintains integrations to client and third-party systems.","inScope":"API and file-based integrations; authentication and access; mailbox and inbox ingestion; error handling and retry; integration monitoring","outOfScope":"The integration decision itself (TL-01); service desk tooling configuration (OPS-01); infrastructure connectivity on the client estate","trigger":"A build requires data from or delivery into another system","inputs":"Access and credentials on both sides; interface specification; data protection position where personal data crosses a boundary","keyActivities":["Establish the interface and its constraints.","Build the integration.","Handle failure paths.","Test end to end with the counterpart system.","Document the flow."],"outputs":"Working integration; data flow documentation; error handling behaviour","definitionOfDone":"Data moves both ways under normal and failure conditions, and the flow is documented","consumes":"BA-03 – Produce functional specifications\nTL-01 – Define and own the solution architecture","feeds":"DEV-02 – Build client-specific applications\nQA-03 – Functional Validation\nExternal: OPS-03 – Integrate monitoring and alerting (Operations, outside this catalogue set)","tools":"No integration pattern library. Data flow documentation exists as MD and README files inside the codebase","reusableAssets":"Integration patterns","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"The agent abstraction layer concept depends on this capability","maturity":"2 - Repeatable","gapsAndRisks":"Integration documentation lives in the codebase, so it is invisible to anyone who is not a developer","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"DEV-04","name":"Fix defects and provide third-line support","owner":[{"name":"TBD","email":null}],"purpose":"Deal with what breaks in production, and with what the first two support lines cannot.","description":"Investigates and fixes defects found in testing or in production, and takes escalations that L1 and L2 cannot resolve.","inScope":"Defect investigation and fix; production incident resolution at code level; root cause analysis; hotfix release","outOfScope":"First and second line support, which is being outsourced (OPS-02); defect triage and tracking (QA-04); infrastructure incidents on the client estate","trigger":"A defect is raised, or an incident is escalated from L2","inputs":"Reproducible defect report; access to the production environment or its logs","keyActivities":["Reproduce and diagnose.","Assess severity and urgency with the service desk.","Fix and test.","Release through the agreed path.","Record the root cause."],"outputs":"Fix in production; root cause note; updated documentation where the cause was a documentation gap","definitionOfDone":"The defect no longer reproduces and the cause is recorded","consumes":"BA-04 – Support acceptance and user validation\nMOB-03 – Mobile testing and device coverage\nQA-03 – Functional Validation\nQA-04 – API / Backend Validation\nQA-09 – Production Validation\nUX-03 – Run design QA on built interfaces\nGap: defect triage and tracking (G-22) – no service in the current catalogue owns this\nExternal: OPS-02 – Run service management operations (Operations, outside this catalogue set)","feeds":"DEV-06 – Release to production\nQA-03 – Functional Validation\nTL-05 – Manage technical risk and technical debt","tools":"Jira. JSM for tickets if a service desk is live","reusableAssets":"Root cause patterns feeding the knowledge base (OPS-01)","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"TBD","pricingUnit":"TBD","contribution":"Whatever support commitment is contracted","maturity":"1 - Ad hoc","gapsAndRisks":"No support model, SLA or on-call arrangement is defined","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"DEV-05","name":"Produce technical documentation","owner":[{"name":"TBD","email":null}],"purpose":"Leave behind enough that someone else can run, extend or take over the system.","description":"Produces the documentation set for a system: architecture and data flow, integration description, configuration, RBAC, and the user-facing guide where one is needed. Today this exists as MD and README files inside the codebase rather than as standalone deliverables.","inScope":"Architecture and data flow documents; integration descriptions; configuration and RBAC matrices; user guide; release notes","outOfScope":"Project documentation such as plans and status (PM-02); service desk knowledge base articles (OPS-01); training delivery (HR-06)","trigger":"A system reaches release, or a handover is due","inputs":"The built system; architecture position; agreed documentation standard, which does not currently exist","keyActivities":["Establish what the receiving party needs.","Write or extract the documentation.","Review for accuracy against the build.","Publish where the receiving party will find it."],"outputs":"Architecture and data flow documents; RBAC matrix; notification configuration sheet; user guide; release notes","definitionOfDone":"Someone who did not build the system can operate it from the documentation alone","consumes":"DEV-02 – Build client-specific applications\nTL-01 – Define and own the solution architecture\nTL-02 – Set and enforce technical standards","feeds":"AEX-01 – Identify reusable assets in delivered work\nAEX-02 – Extract and package an asset\nDEL-03 – Run delivery assurance\nGap: project closure and handover – no service in the current catalogue owns this\nExternal: OPS-01 – Design and implement a service desk (Operations, outside this catalogue set)\nExternal: OPS-02 – Run service management operations (Operations, outside this catalogue set)\nExternal: HR-06 – Map skills and organise training (Human Resources, outside this catalogue set)","tools":"MD and README in-repo. No documentation template set exists","reusableAssets":"Documentation template set","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Handover credibility, and the difference between a reusable asset and a one-off","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"DEV-06","name":"Release to production","owner":[{"name":"TBD","email":null}],"purpose":"Get the build into production without breaking what is already there.","description":"Executes the release: packaging, deployment, verification and rollback if needed. Deployments currently happen during working hours.","inScope":"Release packaging; deployment execution; post-deployment verification; rollback; release communication","outOfScope":"Deciding the environment and deployment approach (TL-04); go-live decision on a client project (PM-02, OPS-01); app store release (MOB-02)","trigger":"A release is ready and a window is agreed","inputs":"Tested build; environment access; agreed window; rollback position","keyActivities":["Package the release.","Confirm the window.","Deploy.","Verify.","Communicate, or roll back."],"outputs":"Deployed release; verification record; release note","definitionOfDone":"The release is live, verified, and the team knows it went out","consumes":"DEV-01 – Build product features\nDEV-02 – Build client-specific applications\nDEV-04 – Fix defects and provide third-line support\nQA-08 – Release Readiness\nTL-04 – Own environments and the deployment approach","feeds":"QA-03 – Functional Validation\nQA-09 – Production Validation\nTL-04 – Own environments and the deployment approach\nUX-03 – Run design QA on built interfaces\nExternal: OPS-02 – Run service management operations (Operations, outside this catalogue set)","tools":"Azure and AWS used as cloud platforms for deployments, Not standardized","reusableAssets":"Release checklist and rollback pattern","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"Not applicable","contribution":"Every live system Twym has delivered","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"DEV-07","name":"Build AI and agent components","owner":[{"name":"TBD","email":null}],"purpose":"Build the retrieval and agent layer that Twym's commercial argument rests on.","description":"Builds the AI-side components.","inScope":"RAG pipelines and retrieval layers; agent design and orchestration; prompt and workflow definition; anonymisation of data leaving the client environment","outOfScope":"The mobile app itself (MOB-01); the service catalogue vocabulary the app consumes; the legal position on data leaving the client environment (LEG-04)","trigger":"A product decision to add an agent or retrieval capability","inputs":"Source content or system to retrieve from; anonymisation position agreed; a defined vocabulary of workflows the agent can invoke","keyActivities":["Establish what the agent must be able to do and say.","Design the retrieval or orchestration layer.","Build and evaluate against real cases.","Confirm the data protection position.","Release and monitor."],"outputs":"Working agent or retrieval layer; evaluation results; anonymisation description","definitionOfDone":"The agent handles the intended cases and the data protection position is documented and holds","consumes":"BPX-03 – Design the target process\nBPX-04 – Produce agent-ready process definitions\nTL-01 – Define and own the solution architecture\nExternal: internal service catalogue – one-time activity, not a catalogue service","feeds":"","tools":"TBD","reusableAssets":"The agent abstraction layer is the highest-value reusable asset","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"The differentiator in the transformation pitch – it becomes the vocabulary the conversational app runs on","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"}]},{"team":"Tech Lead","owner":[{"name":"TBD","email":null}],"members":"Praful B. & Harsh Koralwala as technical entry points","mission":"Make sure what gets built can interlock with everything else and be reused, rather than solving only the request in front of it.","serves":"Both – internal products and client-delivered systems","engage":"Dev Pandya first, as he runs the sprint, then Praful B. & Harsh K. for technical questions. No formal request path.","leadTime":"TBD","capacity":"TBD","maturity":"1 - Ad hoc","interviewStatus":"","confirmedOn":"","sourceFile":"Confluence page 473858050","services":[{"id":"TL-01","name":"Define and own the solution architecture","owner":[{"name":"TBD","email":null}],"purpose":"Decide how a system is put together, and make that decision hold across the products it has to work with.","description":"Produces and owns the architecture for a product or client system: components, data flows, integration points, hosting model.","inScope":"Component and integration architecture; data flows; hosting and deployment topology; reuse and interlock across products; architecture decision records","outOfScope":"Infrastructure design on the client estate, which sits with the client's IT (Cédric at Schellenberg); product scope (PRD-01); detailed implementation (DEV-01)","trigger":"A new product, a significant feature, or an integration decision","inputs":"Product intent or requirements; the existing product estate; hosting and data protection constraints","keyActivities":["Establish constraints, including data protection and hosting.","Draft the architecture and its integration points.","Test it against reuse across the product estate.","Record the decision and its rationale.","Review when the constraints change."],"outputs":"Architecture diagram; integration and data flow description; architecture decision records","definitionOfDone":"The architecture is documented, the reuse question has been answered explicitly, and a developer can build against it","consumes":"BA-01 – Elicit and document requirements\nBA-03 – Produce functional specifications\nPRD-01 – Define and maintain the product vision and roadmap\nPRD-03 – Specify a feature for build","feeds":"BA-03 – Produce functional specifications\nBPX-03 – Design the target process\nBPX-04 – Produce agent-ready process definitions\nDEV-01 – Build product features\nDEV-02 – Build client-specific applications\nDEV-03 – Integrate third-party and client systems\nDEV-05 – Produce technical documentation\nDEV-07 – Build AI and agent components\nPFM-01 – Maintain the platform capability inventory\nPFM-05 – Coordinate the platform roadmap with Tech Lead and Product Portfolio Management\nPPM-01 – Maintain the product portfolio inventory and lifecycle\nTL-02 – Set and enforce technical standards\nTL-04 – Own environments and the deployment approach\nTL-05 – Manage technical risk and technical debt\nUX-02 – Build and maintain the design system\nExternal: conversational mobile application – one-time activity, not a catalogue service","tools":"TBD – MS Visio, http://Draw.io , Camunda Modeler (Self deployed) and Centralized arch platform in future","reusableAssets":"Reference architectures per engagement type; architecture decision record template","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Whether the product estate holds together, and whether client work is reusable","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.2 – 27 August 2026"},{"id":"TL-02","name":"Set and enforce technical standards","owner":[{"name":"TBD","email":null}],"purpose":"Make code from different people and different projects look and behave like it came from one team.","description":"Defines coding standards, repository structure, branching, review practice and documentation expectations, then enforces them through review.","inScope":"Coding and repository standards; code review practice; branching and versioning; in-code documentation expectations; definition of technically done","outOfScope":"Functional acceptance criteria (PRD-03, QA-01); deployment mechanics (TL-04)","trigger":"A new project starts, a new developer joins, or a review finds a recurring problem","inputs":"Agreed toolchain; a repository","keyActivities":["Define the standard.","Publish it where developers will find it.","Review against it.","Revise when it obstructs rather than helps."],"outputs":"Technical standards document; code review checklist; definition of technically done","definitionOfDone":"A new developer can find the standard and their first pull request is reviewed against it","consumes":"TL-01 – Define and own the solution architecture","feeds":"DEV-01 – Build product features\nDEV-02 – Build client-specific applications\nDEV-05 – Produce technical documentation\nMOB-01 – Build mobile features from designs\nQA-02 – Risk & Test Planning\nQA-04 – API / Backend Validation\nQA-10 – Test Automation\nTL-06 – Onboard a developer technically","tools":"Git-based repositories with MD and README documentation. Github actions and GitHub self hosted runners deployed on AWS EC2 are used primarily, mobile team have used GitLab as well for client projects","reusableAssets":"Technical standards set; code review checklist","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal","pricingUnit":"TBD","contribution":"Maintainability of everything handed to a client","maturity":"1 - Ad hoc","gapsAndRisks":"CI/CD pipelines are not managed by DevOps or Cloud engineers yet due to lack of resources in TwymUp for now","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"TL-03","name":"Review feasibility of designs and requirements","owner":[{"name":"TBD","email":null}],"purpose":"Catch the unbuildable before it reaches a sprint.","description":"Reviews specifications, UX flows and screen designs for technical feasibility, effort implications and platform constraints, and states what would have to change. The counterpart of the design and specification services in the UI/UX and Product catalogues.","inScope":"Feasibility assessment of specs and designs; identification of platform constraints; alternatives where a design cannot be built as drawn","outOfScope":"Deciding whether the feature is worth building (PRD-02); estimation, which is not currently produced (PM-05)","trigger":"A specification or design is ready for review","inputs":"The specification or design; the current architecture","keyActivities":["Read the spec or design against the architecture.","Identify constraints and blockers.","Propose alternatives where needed.","Confirm or reject feasibility in writing."],"outputs":"Feasibility opinion; list of required changes or constraints","definitionOfDone":"The specification or design carries a recorded feasibility position before it enters a sprint","consumes":"BA-03 – Produce functional specifications\nPRD-03 – Specify a feature for build\nUX-01 – Produce product screen designs\nUX-02 – Build and maintain the design system\nUX-04 – Define and validate UX flows","feeds":"DEV-01 – Build product features\nMOB-01 – Build mobile features from designs\nPRD-03 – Specify a feature for build\nUX-01 – Produce product screen designs","tools":"TBD","reusableAssets":"Feasibility review checklist","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"Avoids rework, which on a one-week delivery window is the difference between delivering and not","maturity":"1 - Ad hoc","gapsAndRisks":"With no design system and no specification template, there is often nothing concrete to review","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"TL-04","name":"Own environments and the deployment approach","owner":[{"name":"TBD","email":null}],"purpose":"Decide where things run and how they get there, before someone deploys into production by default.","description":"Defines the environment set – development, test, production – the hosting tenancy, and how releases move between them.","inScope":"Environment definition and provisioning; hosting tenancy decision; deployment mechanism; release windows; environment access","outOfScope":"Client infrastructure design (client IT); service desk operations after go-live (OPS-02); the legal position on data location (LEG-04)","trigger":"A new system, a hosting decision, or a release that cannot be made safely with the current set-up","inputs":"Architecture (TL-01); data protection constraints; client tenancy access where relevant","keyActivities":["Define the environments the system needs.","Settle the hosting tenancy against the data protection position.","Define how a release moves to production.","Provision and document access.","Review after each release that went badly."],"outputs":"Environment definition; deployment procedure; access matrix","definitionOfDone":"A release can be made to production by a defined procedure that someone other than its author can follow","consumes":"DEV-06 – Release to production\nTL-01 – Define and own the solution architecture\nExternal: OPS-04 – Run Twym's internal IT and tooling (Operations, outside this catalogue set)","feeds":"DEV-02 – Build client-specific applications\nDEV-06 – Release to production\nMOB-02 – Manage app releases and distribution\nQA-02 – Risk & Test Planning\nQA-03 – Functional Validation\nQA-07 – Performance / Resilience Testing\nQA-10 – Test Automation\nTL-05 – Manage technical risk and technical debt\nExternal: OPS-01 – Design and implement a service desk (Operations, outside this catalogue set)","tools":"Microsoft and Azure tenancy. Atlassian cloud instance for JSM. GitHub Actions manages CI/CD pipeline on a Github Teams plan. AWS.","reusableAssets":"Environment and deployment pattern per engagement type","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Hosting-as-a-service where it is offered case by case","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"TL-05","name":"Manage technical risk and technical debt","owner":[{"name":"TBD","email":null}],"purpose":"Keep a list of what will break later, and make someone decide about it.","description":"Identifies technical risks and accumulated shortcuts, assesses their consequence, and puts them in front of whoever can decide to fix or accept them. Distinct from project risk in that the audience is technical and the mitigation is usually build work.","inScope":"Technical risk register; technical debt log; remediation proposals; input to project risk (PM-04)","outOfScope":"Project, commercial and delivery risk (PM-04, DEL-03); security operations on the client estate (OPS-03)","trigger":"A shortcut is taken knowingly, a constraint is discovered, or a review surfaces a risk","inputs":"Architecture; visibility of what the team actually built","keyActivities":["Record the risk or the debt with its consequence.","Assess likelihood and impact.","Propose remediation with a cost.","Escalate what needs a decision."],"outputs":"Technical risk register; technical debt log with remediation options","definitionOfDone":"Each item is either scheduled for remediation or explicitly accepted by someone with the authority to accept it","consumes":"DEV-01 – Build product features\nDEV-04 – Fix defects and provide third-line support\nTL-01 – Define and own the solution architecture\nTL-04 – Own environments and the deployment approach","feeds":"DEL-03 – Run delivery assurance\nPFM-02 – Prioritise platform investment against product and client demand\nPFM-04 – Manage platform technical debt at portfolio level\nPRD-04 – Agree the weekly delivery scope","tools":"None. Would sit alongside the project risk register","reusableAssets":"Technical risk taxonomy per engagement type","typicalEffort":"TBD","typicalDuration":"Continuous","deliveryModel":"Billable + Internal","pricingUnit":"Not applicable","contribution":"Credibility when a client asks what happens after go-live","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"TL-06","name":"Onboard a developer technically","owner":[{"name":"TBD","email":null}],"purpose":"Get a new developer productive without another developer stopping work to explain the estate.","description":"The technical half of onboarding: access, repositories, local set-up, the product estate, the standards, and who to ask. Complements HR-01, which covers the administrative half.","inScope":"Technical access provisioning; repository and environment set-up; product estate walkthrough; standards induction; naming a technical buddy","outOfScope":"Contract, equipment and administrative onboarding (HR-01, HR-02); client-specific security clearance (OPS-04)","trigger":"A developer joins, or moves onto a new product","inputs":"Accounts and access granted; standards published (TL-02); an ecosystem map (PRD-01)","keyActivities":["Grant technical access.","Walk through the product estate and how the modules interconnect.","Set up the local environment.","Induct on standards.","Assign a first task with a named reviewer."],"outputs":"Technical onboarding checklist, completed; working local environment; first reviewed contribution","definitionOfDone":"The new developer has merged one reviewed change without needing an unscheduled explanation of the estate","consumes":"PRD-01 – Define and maintain the product vision and roadmap\nTL-02 – Set and enforce technical standards\nExternal: HR-01 – Onboard a new joiner (Human Resources, outside this catalogue set)","feeds":"DEV-01 – Build product features\nMOB-01 – Build mobile features from designs","tools":"None. No technical onboarding checklist exists","reusableAssets":"Technical onboarding checklist; the ecosystem walkthrough itself","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"Speed of scaling a delivery team, which is what the regional partner model depends on","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"}]},{"team":"UI / UX","owner":[{"name":"TBD","email":null}],"members":"Akshay Padashala, Dhwani Bode, Aditi Sharma","mission":"Make Twym products usable and coherent by defining how they look and behave, and by holding that definition steady across product lines.","serves":"Both – internal product lines and client-facing engagements","engage":"TBD","leadTime":"1 day","capacity":"All designers are currently occupied","maturity":"2 - Repeatable","interviewStatus":"","confirmedOn":"","sourceFile":"Confluence page 473628675","services":[{"id":"UX-01","name":"Produce product screen designs","owner":[{"name":"Fabien","email":null},{"name":"Nicolas","email":null},{"name":"Dev","email":null},{"name":"Krishna","email":null}],"purpose":"Turn a defined feature scope into screens a developer can build without guessing.","description":"Takes a validated requirement or flow and produces the visual design for each screen: layout, states, content hierarchy, responsive behaviour. Works from the design system where one exists and from first principles where it does not. Ends with a handover a front-end developer can implement against.","inScope":"Component and Variants, Screen with auto-layout; visual hierarchy; empty state, loading and error states; responsive behaviour; annotated developer handover; the flow between screens (UX-04);","outOfScope":"Deciding what the feature should do (PRD); building the components themselves (UX-02);","trigger":"A feature enters the build backlog with an agreed scope","inputs":"Agreed feature scope; the UX flow for the feature; design system components where they exist; brand guidelines","keyActivities":["Review scope and flow with Product Management.","Draft screens using existing components.","Design any state or component the library lacks.","Review with Product Management/Stakeholder and Tech Lead.","Annotate and hand over."],"outputs":"Figma screen designs, Lovable prototypes; all states covered; annotated handover notes;","definitionOfDone":"Screens cover every state, are reviewed by Product Management for scope and Tech Lead for feasibility, and are accessible to the developer building them","consumes":"PRD-03 – Specify a feature for build\nSBD-06 – Own positioning, brand and pricing strategy\nTL-03 – Review feasibility of designs and requirements\nUX-02 – Build and maintain the design system\nUX-04 – Define and validate UX flows\nUX-05 – Produce interactive prototypes for validation","feeds":"DEV-01 – Build product features\nMOB-01 – Build mobile features from designs\nTL-03 – Review feasibility of designs and requirements\nUX-03 – Run design QA on built interfaces","tools":"Figma. No handover annotation standard exists","reusableAssets":"Screen patterns worth generalising back into UX-02","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Every product front end, and any client engagement with a UI component","maturity":"1 - Ad hoc","gapsAndRisks":"Without UX-02 in place, every screen redraws its own components, so effort scales linearly with screen count","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"UX-02","name":"Build and maintain the design system","owner":[{"name":"Akshay","email":null},{"name":"Aditi","email":null},{"name":"Dhwani","email":null}],"purpose":"Provide a shared, reusable visual and interaction foundation so product screens can be designed consistently rather than rebuilt from scratch.","description":"Defines and maintains the shared visual and interaction language across Twym products: tokens (colour, typography, spacing), component library, states and usage rules. Runs as a living asset, versioned. New components arrive from product work, then get generalised back into the library.","inScope":"Design tokens; component library; interaction patterns; accessibility rules; component documentation; versioning and change log","outOfScope":"Front-end component creation; Screen-level design for a specific feature (UX-01); brand identity and logo (SBD)","trigger":"New product line starting, or a feature needing a component the library does not contain","inputs":"Confirmed brand foundations (font, colours, logo); target platforms; front-end framework decision from Tech Lead","keyActivities":["Audit existing screens for repeated patterns.","Define or extend tokens and components.","Review with Product Management and Tech Lead.","Publish the versioned library with usage documentation.","Handle change requests and deprecations."],"outputs":"Figma library file, published and versioned; exported design tokens; component usage documentation; change log","definitionOfDone":"Component published, documented, reviewed by Tech Lead for feasibility, and referenced by at least one screen design","consumes":"SBD-06 – Own positioning, brand and pricing strategy\nTL-01 – Define and own the solution architecture","feeds":"DEV-01 – Build product features\nMOB-01 – Build mobile features from designs\nTL-03 – Review feasibility of designs and requirements\nUX-01 – Produce product screen designs\nUX-03 – Run design QA on built interfaces","tools":"Figma, Lovable, and Claude. TwymWork component available. No Twym component documentation template exists","reusableAssets":"The library itself. Reused across every product and client front end – the highest-leverage reusable asset in this catalogue","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal","pricingUnit":"Not sold standalone. Reduces the design effort priced into client engagements","contribution":"Underpins all product front ends and client-facing UI work","maturity":"2 - Repeatable","gapsAndRisks":"Design-system ownership and capacity need to be formalised. Brand foundations are currently being reviewed, so the token layer cannot be finalised until they are approved","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"UX-03","name":"Run design QA on built interfaces","owner":[{"name":"Akshay","email":null},{"name":"Aditi","email":null},{"name":"Dhwani","email":null}],"purpose":"Check that what was built matches what was designed, before it reaches a client or a demo.","description":"Reviews implemented screens against the design and the design system: spacing, states, typography, interaction behaviour, responsive breakpoints. Produces a defect list with severity, feeding the development backlog. Distinct from functional QA, which checks whether the feature works rather than whether it looks and behaves as specified.","inScope":"Visual fidelity against design; component conformance to the library; interaction and state behaviour; responsive breakpoints; accessibility checks","outOfScope":"Functional testing, test cases and regression (QA); performance testing (QA, TL); deciding whether the feature is the right feature (PRD)","trigger":"A feature reaches a testable build, or a demo date is approaching","inputs":"Deployed build accessible to the reviewer; the approved designs for the scope under review; the published component library","keyActivities":["Walk the built screens against the designs.","Log deviations with severity and screenshot.","Agree severity and scope of fixes with Tech Lead.","Re-check after fixes."],"outputs":"Design defect list with severity and screenshots; sign-off note or explicit list of accepted deviations","definitionOfDone":"Every blocking and major deviation is either fixed or explicitly accepted and recorded before release or demo","consumes":"DEV-01 – Build product features\nDEV-06 – Release to production\nMOB-01 – Build mobile features from designs\nUX-01 – Produce product screen designs\nUX-02 – Build and maintain the design system","feeds":"DEV-04 – Fix defects and provide third-line support\nMOB-01 – Build mobile features from designs\nGap: defect triage and tracking (G-22) – no service in the current catalogue owns this","tools":"No design QA checklist exists – gap to create. Defects should land in Jira alongside functional defects","reusableAssets":"Design QA checklist, once written, is reusable on every engagement","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Demo readiness and client acceptance","maturity":"1 - Ad hoc","gapsAndRisks":"Boundary with functional QA (Vidhi) is undefined. Both could reasonably log the same defect, or neither","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"UX-04","name":"Define and validate UX flows","owner":[{"name":"Fabien","email":null},{"name":"Nicolas","email":null},{"name":"Dev","email":null},{"name":"Krishna","email":null}],"purpose":"Establish the path a user takes through a product before any screen is drawn.","description":"Define end-to-end user journeys and interaction flows to ensure users can complete tasks efficiently. Validate flows through stakeholder reviews, usability testing, and iterative refinements to identify friction points and improve the overall user experience.","inScope":"User journeys and task flows; personas where they inform the flow; decision points and edge cases; information architecture and navigation","outOfScope":"Business process mapping of the client's own operations (BA, BPX); product strategy and what to build (PRD)","trigger":"A new product, module or significant feature enters definition","inputs":"Product intent or requirement from Product Management; access to a user or client stakeholder for validation where possible","keyActivities":["Clarify the user goal and constraints with Product Management.","Map the primary flow and the edge paths.","Review and iterate.","Validate with users or client stakeholders where access allows.","Hand over to screen design."],"outputs":"Flow diagram covering primary and edge paths; navigation and information architecture map; open questions list","definitionOfDone":"Flow reviewed and accepted by Product Management, with edge cases either covered or explicitly deferred and recorded","consumes":"BA-01 – Elicit and document requirements\nPRD-01 – Define and maintain the product vision and roadmap","feeds":"DEV-01 – Build product features\nPRD-03 – Specify a feature for build\nTL-03 – Review feasibility of designs and requirements\nUX-01 – Produce product screen designs\nUX-05 – Produce interactive prototypes for validation","tools":"Figma, FigJam, Lovable, Claude, and Miro. No flow notation standard agreed – gap to create","reusableAssets":"Flow patterns for recurring product problems, e.g. document upload, search and review, case handling","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Product definition quality, and the credibility of early client-facing design work","maturity":"1 - Ad hoc","gapsAndRisks":"Client-facing validation is constrained on Schellenberg, where contact during the build is deliberately minimised for IP reasons. Flows will be validated internally only","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"UX-05","name":"Produce interactive prototypes for validation","owner":[{"name":"Fabien","email":null},{"name":"Nicolas","email":null},{"name":"Dev","email":null},{"name":"Krishna","email":null}],"purpose":"Put something clickable in front of a client or stakeholder before development effort is committed.","description":"Builds a clickable prototype from flows and screens, at whatever fidelity the decision requires, to test an idea or secure client agreement.","inScope":"Clickable prototypes; fidelity choice; demo scripting and narrative support; capture of client feedback into requirement changes","outOfScope":"Production code (DEV); the commercial pitch and storytelling (SBD); the demo environment and data (TL, OPS)","trigger":"A client validation session, a pitch, or an internal decision that needs something tangible","inputs":"The flow (UX-04); enough scope clarity to know what the prototype must prove; a named audience and a date","keyActivities":["Agree what the prototype must prove and to whom.","Choose fidelity.","Build the clickable path.","Run the session and capture feedback.","Feed changes back into flows, designs and scope."],"outputs":"Clickable prototype; session feedback log; list of resulting requirement or scope changes","definitionOfDone":"The session ran, the decision it was built for was taken, and the feedback is recorded somewhere that changes the backlog","consumes":"PRD-01 – Define and maintain the product vision and roadmap\nSBD-01 – Qualify and develop opportunities\nUX-04 – Define and validate UX flows","feeds":"BA-01 – Elicit and document requirements\nPRD-03 – Specify a feature for build\nPRD-06 – Support the pitch and product narrative\nSBD-03 – Run demos and product pitches\nUX-01 – Produce product screen designs","tools":"Figma","reusableAssets":"Prototype patterns, and demo scripts reusable in sales","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Pre-sales, requirements validation, and client agreement on scope","maturity":"2 - Repeatable","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"}]},{"team":"Mobile Development","owner":[{"name":"Jay Panchal","email":null}],"members":"Meet Shah, Sourav Maurya","mission":"Build the mobile surface through which people give Twym instructions and get work back.","serves":"Internal today. The conversational app is intended for delivery leads first.","engage":"Microsoft Teams for task discussions, clarifications, and coordination; JIRA for task and feature management, tracking, and delivery.","leadTime":"Depends on feature scope, complexity, and technical feasibility. Work is divided internally based on priorities, requirements, and workload, with the team aiming to complete work as soon as possible.","capacity":"3-member mobile team. Work is divided internally based on feature requirements, priorities, and workload. The team currently has a planned 2-week roadmap and is working according to it.","maturity":"1 - Ad hoc, 2 - Repeatable, 3 - Documented, 4 - Managed, 5 - Productised","interviewStatus":"","confirmedOn":"3 September 2026","sourceFile":"Confluence page 472252418","services":[{"id":"MOB-01","name":"Build mobile features from designs","owner":[{"name":"Jay Panchal","email":null}],"purpose":"Implement screens and behaviour on mobile from an agreed specification.","description":"The mobile equivalent of DEV-01: takes specified features and designs and implements them for the mobile platform, respecting platform conventions and the design system where one exists.","inScope":"Feature implementation on mobile; platform-specific behaviour; offline and connectivity handling; in-code documentation","outOfScope":"Screen design (UX-01); the conversational layer; backend services (DEV-01)","trigger":"A specified mobile feature enters the build queue","inputs":"Specification and designs; design system components; backend interfaces","keyActivities":["Review the design for mobile feasibility.","Implement.","Handle connectivity and platform edge cases.","Submit for review."],"outputs":"Working mobile feature; reviewed code","definitionOfDone":"Reviewed, merged, and behaving correctly on the supported devices","consumes":"BA-02 – Write user stories and acceptance criteria\nPRD-03 – Specify a feature for build\nPRD-04 – Agree the weekly delivery scope\nTL-02 – Set and enforce technical standards\nTL-03 – Review feasibility of designs and requirements\nTL-06 – Onboard a developer technically\nUX-01 – Produce product screen designs\nUX-02 – Build and maintain the design system\nUX-03 – Run design QA on built interfaces","feeds":"MOB-02 – Manage app releases and distribution\nMOB-03 – Mobile testing and device coverage\nQA-03 – Functional Validation\nUX-03 – Run design QA on built interfaces","tools":"Flutter; GitHub Actions; JIRA; Microsoft Teams","reusableAssets":"Mobile component patterns feeding UX-02","typicalEffort":"Depends on feature scope, complexity, and technical feasibility.","typicalDuration":"Depends on feature scope, complexity, and technical feasibility.","deliveryModel":"Internal today","pricingUnit":"Not applicable yet","contribution":"The mobile surface of TwymWork","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"MOB-02","name":"Manage app releases and distribution","owner":[{"name":"Jay Panchal","email":null}],"purpose":"Get the app onto the phones of the people meant to use it.","description":"Handles versioning, build signing, distribution, and store submission for Android and iOS.","inScope":"Versioning; build signing and provisioning; internal distribution; Google Play Store and Apple App Store submission; release notes","outOfScope":"Server-side release (DEV-06); device management on the corporate estate (OPS-04)","trigger":"A build is ready for users","inputs":"Tested build; signing credentials; distribution channel; device inventory for internal users","keyActivities":["Build and validate the app.","Version and sign the build.","Distribute through Google Play Store or Apple App Store.","Publish release notes."],"outputs":"Distributed build; release notes; version inventory","definitionOfDone":"The intended users are on the intended version","consumes":"MOB-01 – Build mobile features from designs\nMOB-03 – Mobile testing and device coverage\nQA-08 – Release Readiness\nTL-04 – Own environments and the deployment approach\nExternal: conversational mobile application – one-time activity, not a catalogue service","feeds":"","tools":"Flutter; GitHub Actions; JIRA; Microsoft Teams","reusableAssets":"Release and distribution checklist","typicalEffort":"Depends on feature scope, complexity, and technical feasibility.","typicalDuration":"Depends on feature scope, complexity, and technical feasibility.","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"Whether anyone actually uses what was built","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"MOB-03","name":"Mobile testing and device coverage","owner":[{"name":"Jay Panchal","email":null}],"purpose":"Check the app works on the devices people actually hold, not just the one it was built on.","description":"Defines the supported device and OS matrix and tests against it on emulators/simulators and real devices, including permissions, microphone access, connectivity loss, and background behaviour.","inScope":"Latest available Android and iOS OS versions plus relevant lower versions currently available in the market; emulator/simulator and real-device testing; permission and hardware access testing; connectivity and background behaviour","outOfScope":"Functional test design and defect management (QA-02, QA-04); design conformance (UX-03)","trigger":"A build reaches testable state, or the supported device matrix changes","inputs":"Test devices or a device farm; the supported matrix; test cases","keyActivities":["Agree the supported matrix.","Test on emulators/simulators and real devices.","Log defects.","Re-test after fixes.","Upload builds to the Play Store/App Store only after required testing."],"outputs":"Device coverage matrix; test results; defect list","definitionOfDone":"Every supported device and OS combination has been exercised on the release candidate","consumes":"MOB-01 – Build mobile features from designs\nQA-03 – Functional Validation","feeds":"DEV-04 – Fix defects and provide third-line support\nMOB-02 – Manage app releases and distribution\nQA-08 – Release Readiness\nGap: defect triage and tracking (G-22) – no service in the current catalogue owns this","tools":"Flutter; GitHub Actions; JIRA; Microsoft Teams","reusableAssets":"Device matrix and mobile test checklist","typicalEffort":"Depends on feature scope, complexity, and technical feasibility.","typicalDuration":"Depends on feature scope, complexity, and technical feasibility.","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"TBD","maturity":"1 - Ad hoc","gapsAndRisks":"Overlaps QA","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"}]},{"team":"Business Process Extraction","owner":[{"name":"Thery Ehrlich","email":null}],"members":"Thery Ehrlich","mission":"Capture how business activities are performed, in a sufficiently structured way to enable agentic execution.","serves":"Both – client processes on transformation engagements, and Twym's own internal processes","engage":"TBD","leadTime":"TBD","capacity":"TBD","maturity":"1 - Ad hoc","interviewStatus":"","confirmedOn":"","sourceFile":"Confluence page 472121345","services":[{"id":"BPX-01","name":"Assess and prioritise process opportunities","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Identify which business processes offer the strongest opportunities for improvement, automation or agentic execution and should be analysed first.","description":"Screens and compares candidate business processes at a high level to determine where detailed process analysis and transformation effort should be focused. Assesses business value, pain points, volume, manual effort, standardisation, complexity, risk, dependencies and automation potential without performing the detailed process capture itself.","inScope":"Target process design; automation candidate identification; role and responsibility changes; transition path from as-is to target; benefit case","outOfScope":"Detailed as-is process capture (BPX-01); target process design (BPX-02); agent-ready process definition (BPX-03); detailed requirements elicitation (BA-01); technical feasibility and architecture assessment (TL-01); product or portfolio prioritisation outside the process-transformation scope","trigger":"A client or internal function has multiple processes or transformation opportunities and needs to determine where detailed analysis, redesign or automation effort should start","inputs":"Defined business area or transformation scope; access to process owners or knowledgeable stakeholders; available process, workload and performance information; agreed prioritisation criteria","keyActivities":["Note: Key activities in all of the current services are a standard representation of how things are done today to gather business process insights and produce them. This section will evolve as the approach optimisation playbook takes shape."],"outputs":"Process opportunity inventory; process opportunity assessment; prioritisation matrix or scorecard; recommended shortlist for detailed analysis; assumptions and open questions","definitionOfDone":"Candidate processes have been assessed against agreed and transparent criteria, material assumptions and dependencies are visible, and the relevant stakeholders have an agreed or explicitly documented view of which opportunities should proceed to detailed analysis","consumes":"BA-01 – Elicit and document requirements\nSBD-02 – Produce proposals and offers\nExternal: OPS-07 – Design a target operating model (Operations, outside this catalogue set)","feeds":"BPX-02 – Capture an as-is business process\nBPX-03 – Design the target process\nPRD-01 – Define and maintain the product vision and roadmap\nSBD-02 – Produce proposals and offers","tools":"Process opportunity assessment template; prioritisation scorecard; stakeholder interview guide","reusableAssets":"Process opportunity assessment framework; scoring criteria and weighting model; automation and agent suitability criteria; benchmark opportunity patterns by process type or industry","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Provides an evidence-based entry point for transformation engagements by identifying where process redesign, automation and agentic execution are most likely to create value","maturity":"1 - Ad hoc","gapsAndRisks":"No standard opportunity-scoring framework or automation suitability criteria currently exist; assessments may otherwise become subjective, favour highly visible pain points over high-value opportunities, or overestimate automation potential before detailed process analysis","status":"Draft – Proposal","versionDate":"v0.2 – 3 September 2026"},{"id":"BPX-02","name":"Capture an as-is business process","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Capture how a business process actually operates today, including decisions, exceptions, systems and workarounds.","description":"Captures an existing process from the people who perform it through observation, interviews and document review, producing a validated representation of the steps, decisions, hand-offs, systems, exceptions, volumes and pain points that define how the work is actually performed.","inScope":"Process discovery through observation and interview; step, decision and exception mapping; systems touched at each step; volumes and pain points","outOfScope":"Designing the improved process (BPX-03); requirement capture for a system (BA-01); the service catalogue itself","trigger":"A transformation engagement, an automation candidate...","inputs":"Access to the people who perform the process; the scope boundary; a notation, which does not currently exist","keyActivities":["Define the process boundary, trigger and outcome.Identify the relevant performers and information sources.Observe, interview and review available documentation.Map activities, decisions, hand-offs, systems, exceptions and workarounds.Capture relevant volumes, pain points and constraints.Validate the process with the people who perform it."],"outputs":"As-is process map; exception and workaround list; systems touched; pain points","definitionOfDone":"The people who perform the process agree the map is what they actually do, including the exceptions","consumes":"BA-01 – Elicit and document requirements\nBPX-01 – Assess and prioritise process opportunities\nExternal: internal service catalogue – one-time activity, not a catalogue service","feeds":"BA-01 – Elicit and document requirements\nBPX-03 – Design the target process\nBPX-04 – Produce agent-ready process definitions\nBPX-05 – Maintain the process repository\nBPX-06 – Measure process performance and benefit\nExternal: OPS-07 – Design a target operating model (Operations, outside this catalogue set)\nExternal: internal service catalogue – one-time activity, not a catalogue service","tools":"TBD","reusableAssets":"Process capture interview guide; a chosen notation standard","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable","pricingUnit":"TBD","contribution":"The consulting half of the transformation offer","maturity":"2 - Repeatable","gapsAndRisks":"No notation, no repository and no completed map exists.","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"BPX-03","name":"Design the target process","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Design how a business process should operate in the target state to improve performance and enable appropriate automation.","description":"Redesigns a validated as-is process into a target operating flow by determining what should be removed, simplified, automated or retained as human activity, and defining the required changes to roles, systems, controls and hand-offs.","inScope":"Target process design; automation candidate identification; role and responsibility changes; transition path from as-is to target; benefit case","outOfScope":"Building the automation (DEV-07, DEV-01); the operating model around the process (OPS-07); change management delivery, which currently has no owner","trigger":"An as-is capture is complete and a decision to change is taken","inputs":"Validated as-is map; the constraints, including system and legal ones; a sponsor who can change how people work","keyActivities":["Assess the as-is process for waste, duplication, bottlenecks and control issues.Identify improvement and automation opportunities within the process.Design the target activities, decisions and hand-offs.Define required changes to roles, responsibilities, systems and controls.Define expected benefits and relevant constraints.Agree the target process and transition approach with the relevant stakeholders."],"outputs":"Target process design; automation candidate list; role change summary; benefit case","definitionOfDone":"The sponsor has accepted the target and the transition path has an owner","consumes":"BPX-01 – Assess and prioritise process opportunities\nBPX-02 – Capture an as-is business process\nTL-01 – Define and own the solution architecture\nExternal: OPS-07 – Design a target operating model (Operations, outside this catalogue set)","feeds":"BA-01 – Elicit and document requirements\nBA-03 – Produce functional specifications\nBPX-04 – Produce agent-ready process definitions\nBPX-05 – Maintain the process repository\nBPX-06 – Measure process performance and benefit\nDEV-07 – Build AI and agent components\nExternal: OPS-07 – Design a target operating model (Operations, outside this catalogue set)","tools":"None","reusableAssets":"Target process patterns per industry","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable","pricingUnit":"TBD","contribution":"What makes the transformation offer more than an infrastructure project","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"BPX-04","name":"Produce agent-ready process definitions","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Define a process precisely enough for an AI agent or automation solution to implement it consistently and safely.","description":"Converts an agreed process design into a structured implementation-ready definition covering ordered activities, decision rules, required inputs and outputs, system interactions, exceptions, escalation paths and human supervision points.","inScope":"Machine-executable process definition; decision rules and their thresholds; input and output specifications; exception and escalation handling; the human supervision point","outOfScope":"Building the agent (DEV-07); the mobile invocation layer; model or tooling selection (TL-07 territory, not yet defined)","trigger":"A process is designated for automation, or a service in the catalogue must become invocable","inputs":"Target process design; system interfaces; the data protection position where the process touches personal data","keyActivities":["Decompose the process into explicit activities and transitions.Define decision rules and required conditions.Specify inputs, outputs and system interactions for each relevant step.Define exceptions, failure handling and escalation paths.Define where human review, approval or intervention is required.Validate the definition against representative normal and edge cases."],"outputs":"Agent-ready process definition; decision rule set; exception and escalation map","definitionOfDone":"A developer can build an agent from the definition without asking what happens in an edge case","consumes":"BPX-02 – Capture an as-is business process\nBPX-03 – Design the target process\nTL-01 – Define and own the solution architecture\nExternal: internal service catalogue – one-time activity, not a catalogue service","feeds":"DEV-07 – Build AI and agent components\nPFM-01 – Maintain the platform capability inventory\nGap: integrating the app with workflows and back-end systems (G-10) – no service in the current catalogue owns this\nExternal: OPS-02 – Run service management operations (Operations, outside this catalogue set)","tools":"TBD","reusableAssets":"The definition format itself. If it works, it is what makes every subsequent process automatable at low cost","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"TBD","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"BPX-05","name":"Maintain the process repository","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Keep documented processes governed, findable, versioned and aligned with how the business actually operates.","description":"Maintains the authoritative repository of captured and designed processes, including ownership, status, version history and review cycles, so that process documentation remains current and reusable as the organisation changes.","inScope":"Process register; versioning and ownership per process; review cycle; retirement of processes that no longer run","outOfScope":"The service catalogue register; the asset library (AEX-03); the corporate information space (HR-04)","trigger":"A process is captured, changed or retired","inputs":"A location; a register format; named process owners","keyActivities":["Register each process with its owner, status and version.Maintain the authoritative process artefacts and metadata.Define and monitor review cycles.Update process records when approved changes occur.Identify processes that are overdue for review.Retire or archive processes that are no longer active."],"outputs":"Process register; version history; review schedule","definitionOfDone":"Every registered process has an owner and was reviewed within its cycle","consumes":"BPX-02 – Capture an as-is business process\nBPX-03 – Design the target process","feeds":"AEX-03 – Maintain the asset library\nExternal: internal service catalogue – one-time activity, not a catalogue service\nExternal: HR-04 – Build and maintain the corporate information space (Human Resources, outside this catalogue set)\nExternal: HR-06 – Map skills and organise training (Human Resources, outside this catalogue set)","tools":"TBD","reusableAssets":"The register structure and the review cadence","typicalEffort":"TBD","typicalDuration":"Continuous","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Process documentation as a client deliverable that stays true after handover","maturity":"1 - Ad hoc","gapsAndRisks":"Overlaps the service catalogue register and the asset library.","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"BPX-06","name":"Measure process performance and benefit","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Measure whether a process change delivered the expected operational and business benefit.","description":"Defines measurable process outcomes, establishes the pre-change baseline and compares performance after implementation to determine whether the redesigned or automated process delivered the expected benefit.","inScope":"Baseline measurement; benefit definition and metrics; post-change measurement; exception rate tracking for automated processes","outOfScope":"Financial reporting (ACC-05); project status reporting (PM-02); the client's own operational KPIs outside the process boundary","trigger":"A process change is proposed, and again after it is implemented","inputs":"As-is process with volumes; agreed benefit metrics; access to the data that measures them","keyActivities":["Define the expected process outcomes and measures of success.Establish the pre-change baseline.Define how and when post-change performance will be measured.Measure actual performance after implementation.Analyse deviations, including exception rates for automated or agent-driven processes.Report whether the expected benefit was achieved and identify material gaps."],"outputs":"Baseline measures; benefit assessment; exception rate reporting","definitionOfDone":"The claimed benefit is either evidenced or explicitly not evidenced","consumes":"BA-05 – Analyse data and define reporting\nBPX-02 – Capture an as-is business process\nBPX-03 – Design the target process","feeds":"PRD-01 – Define and maintain the product vision and roadmap\nSBD-02 – Produce proposals and offers\nExternal: delivery cockpit – one-time activity, not a catalogue service","tools":"TBD","reusableAssets":"Benefit measurement framework – the reference case for selling the next transformation","typicalEffort":"TBD","typicalDuration":"Baseline and post-change measurement points","deliveryModel":"Billable","pricingUnit":"TBD","contribution":"TBD","maturity":"1 - Ad hoc","gapsAndRisks":"No process has been baselined yet","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"}]},{"team":"Business Analysis","owner":[{"name":"Thery Ehrlich","email":null}],"members":"Thery Ehrlich","mission":"Establish what a client actually needs, in enough detail that someone can build it and someone else can test it.","serves":"Both – client engagements and internal product definition","engage":"TBD","leadTime":"TBD","capacity":"One named analyst across two client engagements plus internal product work, and holding a second function.","maturity":"1 - Ad hoc","interviewStatus":"","confirmedOn":"","sourceFile":"Confluence page 471990273","services":[{"id":"BA-01","name":"Elicit and document requirements","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Establish a clear, agreed and traceable set of business and system requirements from stakeholder needs.","description":"Runs requirements elicitation and analysis with the client or internal requester through interviews, workshops, document review and other appropriate techniques, and produces a structured requirement set for downstream specification and delivery.","inScope":"Stakeholder identification; elicitation planning; stakeholder interviews and workshops; document analysis; requirement capture, classification and structuring; functional and non-functional requirements; business rules, assumptions and constraints; scope boundary definition; confirmation of elicitation results; requirement verification and validation; traceability from need to requirement; management of open questions and agreed requirement changes","outOfScope":"Product prioritisation (PRD-02); detailed user stories and acceptance criteria (BA-02); UX flows (UX-04); detailed functional specifications (BA-03); technical design (TL-01); process mapping of the client's operations (BPX-02)","trigger":"A project, feature or change needs requirements, or an existing requirement set is incomplete, ambiguous, outdated or no longer aligned with the business need","inputs":"Business objective or problem to solve; initial scope and known constraints; access to relevant stakeholders; available source material","keyActivities":["Identify stakeholders and information sources.Prepare and conduct elicitation through interviews, workshops, document analysis or other appropriate techniques.Confirm the information captured and resolve gaps or contradictions.Structure and document the requirements, assumptions, constraints and business rules.Verify that the requirements are clear, consistent and sufficiently complete.Validate that they support the underlying business need and agreed scope.Establish traceability and obtain stakeholder confirmation.","Maintain the requirement set through agreed change."],"outputs":"Requirements package; requirement catalogue; scope boundary statement; assumptions and constraints; open questions and decisions list; requirement traceability","definitionOfDone":"The relevant stakeholders have confirmed the requirement set; requirements are clear, consistent and traceable to the underlying need; material assumptions, constraints and unresolved questions are visible; and downstream specification or delivery can proceed without material ambiguity about what is required","consumes":"BPX-02 – Capture an as-is business process\nBPX-03 – Design the target process\nSBD-02 – Produce proposals and offers\nUX-05 – Produce interactive prototypes for validation","feeds":"BA-02 – Write user stories and acceptance criteria\nBA-03 – Produce functional specifications\nBA-05 – Analyse data and define reporting\nBA-06 – Manage requirements lifecycle and change\nBPX-01 – Assess and prioritise process opportunities\nBPX-02 – Capture an as-is business process\nDEV-02 – Build client-specific applications\nPRD-03 – Specify a feature for build\nQA-01 – Requirement Quality Review\nQA-02 – Risk & Test Planning\nTL-01 – Define and own the solution architecture\nUX-04 – Define and validate UX flows","tools":"TBD","reusableAssets":"Requirements template; interview guide per engagement type","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"TBD","maturity":"2 - Repeatable","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"BA-02","name":"Write user stories and acceptance criteria","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Turn a requirement into a ticket a developer can build and a tester can prove.","description":"Decomposes agreed requirements or feature definitions into appropriately sliced user stories, each with the context, business rules and acceptance criteria required for delivery.","inScope":"Story decomposition; acceptance criteria; story sizing to the delivery window; backlog structuring","outOfScope":"Prioritising the backlog (PRD-02, PRD-04); test case design (QA-02); estimation, which is not produced","trigger":"A requirement is agreed and enters the build queue","inputs":"Confirmed requirements; the delivery cadence; awareness of what the team can absorb in a sprint","keyActivities":["Understand the source requirement, feature and intended outcome.Decompose and slice it into coherent user stories.Document relevant business rules, dependencies and assumptions.Write clear and testable acceptance criteria.Review with the Tech Lead for feasibility and QA for testability.Link each story to its source requirement or feature and load it into Jira."],"outputs":"User stories in Jira with acceptance criteria","definitionOfDone":"QA can write a test from the story without asking a question, and the developer does not reinterpret it","consumes":"BA-01 – Elicit and document requirements\nBA-06 – Manage requirements lifecycle and change\nPRD-03 – Specify a feature for build","feeds":"DEV-01 – Build product features\nDEV-02 – Build client-specific applications\nMOB-01 – Build mobile features from designs\nPRD-04 – Agree the weekly delivery scope\nQA-01 – Requirement Quality Review\nQA-03 – Functional Validation","tools":"Jira","reusableAssets":"Story and acceptance criteria pattern set","typicalEffort":"TBD","typicalDuration":"Per sprint cycle","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"The link between what was sold and what gets built","maturity":"3 - Documented","gapsAndRisks":"With no acceptance criteria in practice, there is no objective definition of done at story level anywhere in the delivery chain","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"BA-03","name":"Produce functional specifications","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Describe how the solution must behave in enough functional detail to design, build, test and contract against it.","description":"Produces the functional specification for a system or significant module, translating agreed requirements into precise behaviour, rules, information, roles, permissions and functional interface requirements.","inScope":"Functional behaviour and rules; data definitions; roles and permissions including RBAC; interface specifications; non-functional requirements where stated","outOfScope":"Technical design and architecture (TL-01); UI design (UX-01); test cases (QA-02)","trigger":"A build is significant enough, or contracted tightly enough, that stories alone are insufficient","inputs":"Confirmed requirements; the process model where one exists; architecture constraints","keyActivities":["Define the structure and boundaries of the specification.Specify functional behaviour, scenarios, rules and exceptions.Define required information, roles and permissions.Define functional inputs, outputs and interface behaviour without prescribing the technical implementation.Model complex behaviour where needed.Verify the specification for completeness, consistency and ambiguity and validate it against the source requirements.Review with the Tech Lead and client.Establish traceability, baseline the approved specification and manage agreed changes against it."],"outputs":"Functional specification; RBAC matrix; interface definitions","definitionOfDone":"The client has signed it, and a supplier could be held to it","consumes":"BA-01 – Elicit and document requirements\nBA-06 – Manage requirements lifecycle and change\nBPX-03 – Design the target process\nTL-01 – Define and own the solution architecture","feeds":"BA-04 – Support acceptance and user validation\nDEV-02 – Build client-specific applications\nDEV-03 – Integrate third-party and client systems\nQA-02 – Risk & Test Planning\nTL-01 – Define and own the solution architecture\nTL-03 – Review feasibility of designs and requirements","tools":"TBD","reusableAssets":"Functional specification template; RBAC matrix pattern","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable","pricingUnit":"TBD","contribution":"Directly commercial – it is what makes a fixed price defensible","maturity":"2 - Repeatable","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"BA-04","name":"Support acceptance and user validation","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Help the client determine, with traceable evidence, whether the delivered solution satisfies the agreed requirements and is acceptable for use.","description":"Prepares and supports business and user acceptance by defining what will be validated, against which requirements and acceptance criteria, by whom, and how findings, deviations and acceptance decisions will be handled.","inScope":"Acceptance criteria at deliverable level; client test preparation and support; gap triage against requirements; acceptance record","outOfScope":"Test execution by QA (QA-03); defect management (QA-04); design conformance (UX-03)","trigger":"A deliverable approaches acceptance or go-live","inputs":"Requirements or specification to accept against; client testers with time allocated; a working build","keyActivities":["Define the acceptance scope, criteria and responsibilities for the deliverable.Trace acceptance scenarios to the relevant requirements or specification.Prepare the client's UAT or acceptance material.Support users through validation and clarify expected behaviour where necessary.Triage findings as defects, requirement gaps, changes or accepted deviations with the relevant delivery roles.Track unresolved acceptance items.Record the final acceptance decision and any accepted deviations."],"outputs":"Acceptance criteria; client test material; acceptance record with accepted deviations","definitionOfDone":"The client has accepted in writing, with any deviations named","consumes":"BA-03 – Produce functional specifications\nDEL-03 – Run delivery assurance\nQA-08 – Release Readiness","feeds":"DEV-04 – Fix defects and provide third-line support\nGap: project closure and handover – no service in the current catalogue owns this\nGap: defect triage and tracking (G-22) – no service in the current catalogue owns this\nExternal: ACC-01 – Invoice clients (Accounting, outside this catalogue set)","tools":"TBD","reusableAssets":"Acceptance pack template","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable","pricingUnit":"TBD","contribution":"The point at which an invoice becomes defensible","maturity":"2 - Repeatable","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"BA-05","name":"Analyse data and define reporting","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Define what a report or metric means, where its data comes from and how it must be calculated before someone builds it.","description":"Establishes reporting requirements, data provenance, business definitions, calculation rules and source-data quality so that reports and metrics have an agreed and reproducible meaning.","inScope":"Data provenance mapping; metric and field definitions; reporting requirements; data quality assessment","outOfScope":"Building the reports (DEV-01); the cockpit's design and action set; finance reporting content (ACC-05)","trigger":"A dashboard, report or metric is requested","inputs":"Access to the candidate source systems; a stated question the report must answer","keyActivities":["Establish the business question, audience and decision the report must supportDefine each metric, dimension, field and relevant business rule.Identify the required level of detail, filters and reporting period.Trace each required data element to its candidate source and define the calculation or transformation logic.Assess source-data availability and quality.Identify gaps, conflicts and assumptions.Review the definitions and provenance with the relevant business and technical owners.Hand the agreed reporting requirements and provenance map to the build team."],"outputs":"Data provenance map; metric definitions; data quality findings","definitionOfDone":"Every field on the proposed report resolves to a named source, or is flagged as having none","consumes":"BA-01 – Elicit and document requirements","feeds":"BPX-06 – Measure process performance and benefit\nDEV-01 – Build product features\nExternal: delivery cockpit – one-time activity, not a catalogue service\nExternal: ACC-05 – Produce management reporting (Accounting, outside this catalogue set)","tools":"Jira, Tempo, Confluence, Wrike, HubSpot, Bexio, TwymAtlas","reusableAssets":"Data provenance map per account – directly reusable across engagements","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"TBD","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"BA-06","name":"Manage requirements lifecycle and change","owner":[{"name":"Thery Ehrlich","email":null}],"purpose":"Keep requirements controlled, traceable and aligned as scope and delivery evolve.","description":"Maintains the requirements baseline throughout delivery, assesses the impact of proposed changes and keeps requirements, specifications, stories and acceptance evidence traceable to one another.","inScope":"Requirements baselining; traceability; version and status management; change impact analysis; requirement dependencies; requirement approval status; identification of affected specifications, stories and tests","outOfScope":"Product prioritisation (PRD-02); project change governance (PM-04); technical impact assessment (TL-01); defect management (QA-04)","trigger":"An approved requirement changes, new information affects the agreed baseline, or traceability needs to be maintained across delivery","inputs":"Approved requirement baseline; proposed change or new information; links to downstream delivery artefacts","keyActivities":["Maintain the requirement baseline and status.Maintain traceability between needs, requirements, specifications, stories and acceptance evidence.Assess the functional and scope impact of proposed changes.Identify affected downstream artefacts and stakeholders.Record the approved outcome.Update the baseline and traceability after approval."],"outputs":"Updated requirement baseline; traceability matrix or links; requirement change impact assessment; requirement status record","definitionOfDone":"Requirements and their downstream artefacts reflect the approved state, and the impact and disposition of material changes can be traced","consumes":"BA-01 – Elicit and document requirements","feeds":"BA-02 – Write user stories and acceptance criteria\nBA-03 – Produce functional specifications","tools":"Jira, Tempo, Confluence, Wrike, HubSpot, Bexio, TwymAtlas","reusableAssets":"Data provenance map per account – directly reusable across engagements","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"TBD","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.2 – 3 September 2026"}]},{"team":"Sales & Business Development","owner":[{"name":"Fabien Clerc","email":null}],"members":"TBD","mission":"Win the right clients and grow the accounts Twym already has.","serves":"External – clients and prospects; internally, everyone whose work it funds","engage":"TBD","leadTime":"TBD","capacity":"TBD","maturity":"2 - Repeatable","interviewStatus":"","confirmedOn":"","sourceFile":"Confluence page 468942849","services":[{"id":"SBD-01","name":"Qualify and develop opportunities","owner":[{"name":"Fabien Clerc","email":null}],"purpose":"Decide which opportunities are to be pursued.","description":"Identifies, qualifies and develops opportunities through to a proposal. Covers both new logos and growth inside existing accounts.","inScope":"Opportunity identification and qualification; client relationship development; needs discovery; pipeline progression to proposal","outOfScope":"Writing the proposal (SBD-02); demo delivery (SBD-03); delivery-side growth spotting (DEL-06)","trigger":"An inbound approach, an introduction, or a growth signal from a live engagement","inputs":"Target market definition; delivery capacity picture; the product estate's real maturity","keyActivities":["Identify and make contact.","Discover the need.","Qualify against the target profile and against capacity.","Develop the relationship to a proposal point.","Record in the CRM."],"outputs":"Qualified opportunity in HubSpot; needs summary; qualification decision","definitionOfDone":"The opportunity is either progressed to proposal or closed with a recorded reason","consumes":"DEL-06 – Build and run the account growth playbook\nPRD-05 – Run market and opportunity research\nSBD-03 – Run demos and product pitches\nSBD-04 – Maintain client typology and account plans","feeds":"PRD-01 – Define and maintain the product vision and roadmap\nPRD-05 – Run market and opportunity research\nSBD-02 – Produce proposals and offers\nSBD-03 – Run demos and product pitches\nSBD-04 – Maintain client typology and account plans\nSBD-07 – Maintain the CRM and pipeline reporting\nUX-05 – Produce interactive prototypes for validation","tools":"HubSpot as CRM. No qualification criteria written down","reusableAssets":"Qualification criteria; the target profile as a stated filter","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"The front of everything","maturity":"2 - Repeatable","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"SBD-02","name":"Produce proposals and offers","owner":[{"name":"Fabien Clerc","email":null}],"purpose":"Put a scope, a price and a commitment in writing.","description":"Produces the commercial proposal: scope, approach, team, timeline, price and terms.","inScope":"Scope and approach definition; pricing and commercial structure; proposal writing; negotiation to signature","outOfScope":"Contract drafting and terms (LEG-01); delivery set-up after signature (DEL-04); technical solution design (TL-01)","trigger":"A qualified opportunity reaches proposal stage","inputs":"Qualified need; delivery approach and rough shape from Delivery; pricing position; legal position on terms","keyActivities":["Define scope and approach with Delivery.","Structure the commercial model.","Price it.","Write and issue the proposal.","Negotiate to signature."],"outputs":"Written proposal; pricing; signed offer","definitionOfDone":"Signed, with a scope Delivery recognises as the one they were asked about","consumes":"AEX-03 – Maintain the asset library\nAEX-05 – Assess productisation and the IP position\nBPX-01 – Assess and prioritise process opportunities\nBPX-06 – Measure process performance and benefit\nDEL-02 – Define and maintain the delivery method\nDEL-04 – Set up a new engagement\nPRD-06 – Support the pitch and product narrative\nSBD-01 – Qualify and develop opportunities\nSBD-04 – Maintain client typology and account plans\nSBD-06 – Own positioning, brand and pricing strategy\nExternal: OPS-07 – Design a target operating model (Operations, outside this catalogue set)","feeds":"BA-01 – Elicit and document requirements\nBPX-01 – Assess and prioritise process opportunities\nDEL-04 – Set up a new engagement\nExternal: ACC-01 – Invoice clients (Accounting, outside this catalogue set)","tools":"No proposal template, no rate card, no corporate document templates. Branding pack in review","reusableAssets":"Proposal template per engagement typology; pricing patterns per model","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"Every engagement starts here","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"SBD-03","name":"Run demos and product pitches","owner":[{"name":"Fabien Clerc","email":null}],"purpose":"Show a prospect something working, and find out what they actually want.","description":"Prepares and delivers product demonstrations.","inScope":"Demo preparation and delivery; audience selection; capturing what the audience reacted to; converting reaction into an opportunity","outOfScope":"Building the demo asset (UX-05, DEV-01); the product narrative content (PRD-06); managing expectations on delivery maturity, which sits with the project","trigger":"A prospect or client meeting where something can be shown","inputs":"A demonstrable asset; narrative and script; the right audience","keyActivities":["Choose the audience and the message.","Prepare the asset and script with Product.","Deliver.","Capture reaction and follow-up.","Convert into an opportunity or a product decision."],"outputs":"Delivered demo; reaction and follow-up notes; resulting opportunities","definitionOfDone":"The reaction is recorded and either an opportunity or a product decision follows","consumes":"PRD-01 – Define and maintain the product vision and roadmap\nPRD-06 – Support the pitch and product narrative\nSBD-01 – Qualify and develop opportunities\nUX-05 – Produce interactive prototypes for validation","feeds":"PRD-01 – Define and maintain the product vision and roadmap\nPRD-06 – Support the pitch and product narrative\nSBD-01 – Qualify and develop opportunities\nSBD-07 – Maintain the CRM and pipeline reporting","tools":"Lovable and Figma used for prototypes. No demo environment or demo data set is described","reusableAssets":"Demo scripts and reusable demo assets","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"The route by which every current product opportunity was created","maturity":"2 - Repeatable","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"SBD-04","name":"Maintain client typology and account plans","owner":[{"name":"Fabien Clerc","email":null}],"purpose":"Classify each client so delivery and growth can be run from a pattern rather than from scratch.","description":"Fabien's classification exercise as of 23 August: IT transformation, Professional services and outsourcing, Pilot. Each typology should get playbooks covering how Twym delivers and how it grows the account.","inScope":"Engagement typology definition; classification of each account; account plans and growth ambition; the commercial half of the growth playbook","outOfScope":"The delivery half of the growth playbook (DEL-06); portfolio management inside an account (PM-03); pipeline reporting (SBD-07)","trigger":"A new account, or the typology extension","inputs":"Account knowledge from delivery; CRM data; the typology definitions","keyActivities":["Define the typologies.","Classify each account.","Set the growth ambition per account.","Build the growth playbook per typology with Delivery.","Review on a cycle."],"outputs":"Engagement typology; account classification; account plans; growth playbook per typology","definitionOfDone":"Every account has a typology and a stated growth ambition that Delivery has seen","consumes":"SBD-01 – Qualify and develop opportunities\nSBD-07 – Maintain the CRM and pipeline reporting\nExternal: delivery cockpit – one-time activity, not a catalogue service","feeds":"AEX-04 – Reapply an asset to a new engagement\nDEL-04 – Set up a new engagement\nDEL-06 – Build and run the account growth playbook\nPRD-01 – Define and maintain the product vision and roadmap\nPRD-05 – Run market and opportunity research\nSBD-01 – Qualify and develop opportunities\nSBD-02 – Produce proposals and offers\nSBD-05 – Define regional partner demand and proposition\nSBD-07 – Maintain the CRM and pipeline reporting","tools":"HubSpot. No account plan template exists","reusableAssets":"The typology itself, plus an account plan template per typology","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"The frame the delivery playbooks are built against","maturity":"1 - Ad hoc","gapsAndRisks":"Three accounts is a thin base for a typology. The growth playbook straddles this function and Delivery, and the split has not been agreed","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"SBD-05","name":"Define regional partner demand and proposition","owner":[{"name":"Fabien Clerc (proposed","email":null},{"name":"to confirm)","email":null}],"purpose":"Tell Delivery where Twym needs local delivery capacity and at what rates, and give local firms a reason to work with Twym.","description":"Sales' part of the regional delivery partner model, before Twym opens an office in a new country. For each location Sales states the demand signal, the target accounts and sectors, the capacity needed and the day-rate ceiling derived from the target gross margin, and designates the strategic accounts where partner staff appear as Twym. It also drafts the one-page partner proposition used at first contact with firms. Delivery selects the firms (DEL-10); Operations manages them after the CEO's approval and contracting (OPW-05, OPE-05). Sales defines the commercial need; it does not own sourcing, assessment, selection, onboarding or ongoing partner management. Sales is consulted on rates at the conflict screen and on the final selection decision. Reference: Partner Selection Playbook and Partner Contracting, Onboarding and Governance Playbook.","inScope":"Location brief (demand signal and commercial rationale; target sectors, client types, languages and strategic-account context; required capacity, roles and timing; day-rate ceiling and target margin assumptions; expected presentation models and default risk tier); designation of strategic accounts; the partner proposition, the external page that explains what Twym offers and asks; Sales input on rates at the conflict screen and on the selection decision","outOfScope":"Sourcing, assessment and selection of firms (DEL-10); onboarding, governance and ongoing management of selected partners (OPW-05, OPE-05); partner contracting terms (LEG-02); recruiting employees (HR-03)","trigger":"A target geography is identified, or an engagement needs local capacity","inputs":"Target location and demand signal; target gross margin; account strategy (SBD-04); positioning (SBD-06)","keyActivities":["Set out the demand signal and the commercial rationale for the location.","Define sectors, client types, languages, strategic accounts, capacity, roles and timing.","Set the day-rate ceiling and the target margin assumptions from likely client pricing and delivery model.","Propose the presentation models and the default risk tier.","Draft the location brief for CEO approval.","Draft and maintain the partner proposition.","Advise on rates at the conflict screen and on the final decision."],"outputs":"Approved location brief (including day-rate ceiling, target margin assumptions and strategic accounts); partner proposition page","definitionOfDone":"The CEO has approved the location brief and Delivery can start sourcing; the proposition page is approved and in use","consumes":"SBD-04 – Maintain client typology and account plans\nSBD-06 – Own positioning, brand and pricing strategy","feeds":"DEL-10 – Select regional delivery partners","tools":"Location brief template (Partner Selection Playbook, Annex A); partner proposition page (Annex B)","reusableAssets":"Location brief and day-rate ceiling per location; the partner proposition page","typicalEffort":"Twym proposal: the location brief is the first step of a 10-week plan per location","typicalDuration":"Week 1 of the location plan","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"Geographic expansion without carrying the fixed cost of an office","maturity":"1 - Ad hoc","gapsAndRisks":"Owner not yet confirmed with Fabien Clerc. The proposition page waits for the website and for the positioning text (root NOTES, 2026-08-23). The Sales-to-Delivery hand-over after signature is not covered by any service (G-24)","status":"Draft – Proposal","versionDate":"v0.3 – 2 October 2026"},{"id":"SBD-06","name":"Own positioning, brand and pricing strategy","owner":[{"name":"TBD","email":null}],"purpose":"Decide what Twym says it is, and what it charges for it.","description":"Covers market positioning, brand identity, website and external communication, and pricing strategy.","inScope":"Positioning and messaging; brand identity, font, logo, colours; website; corporate templates; pricing strategy; external communication","outOfScope":"Product-specific narrative for a pitch (PRD-06); the design system for products (UX-02); deal-level pricing (SBD-02)","trigger":"Brand review, a new product launch, or a positioning question","inputs":"Market position from research; the product estate; a decision on who owns external communication","keyActivities":["Settle the brand foundations.","Define positioning and messaging.","Produce corporate templates.","Set pricing strategy.","Decide the external communication approach."],"outputs":"Brand pack – font, logo, colours; corporate slide and document templates; positioning statement; pricing strategy","definitionOfDone":"Anyone at Twym can produce a client-facing document that looks like Twym without asking","consumes":"PRD-01 – Define and maintain the product vision and roadmap\nPRD-05 – Run market and opportunity research","feeds":"DEL-02 – Define and maintain the delivery method\nPRD-06 – Support the pitch and product narrative\nSBD-02 – Produce proposals and offers\nSBD-05 – Define regional partner demand and proposition\nUX-01 – Produce product screen designs\nUX-02 – Build and maintain the design system\nExternal: HR-01 – Onboard a new joiner (Human Resources, outside this catalogue set)","tools":"Brand pack. No corporate slide or document templates exist","reusableAssets":"The brand pack and the template set, which unblock document production across every other function","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"Every client-facing artefact","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"SBD-07","name":"Maintain the CRM and pipeline reporting","owner":[{"name":"Fabien Clerc","email":null}],"purpose":"Keep the commercial picture in a system rather than in one person's head.","description":"Maintains HubSpot as the commercial record and produces the pipeline view. Named in the record as the source for the account growth information the account cockpit needs.","inScope":"CRM hygiene and stage discipline; pipeline reporting; account and contact records; commercial data feed into the cockpit","outOfScope":"Finance and invoicing data (ACC-05); delivery status (PM-02); account planning content (SBD-04)","trigger":"Any commercial activity, plus the reporting cycle","inputs":"HubSpot; agreed pipeline stages; discipline in recording","keyActivities":["Record opportunities and contacts.","Keep stages current.","Produce the pipeline view.","Feed the cockpit."],"outputs":"Current CRM; pipeline report; commercial feed to the delivery cockpit","definitionOfDone":"The pipeline view is current enough that someone else could brief on it","consumes":"SBD-01 – Qualify and develop opportunities\nSBD-03 – Run demos and product pitches\nSBD-04 – Maintain client typology and account plans","feeds":"DEL-06 – Build and run the account growth playbook\nSBD-04 – Maintain client typology and account plans\nExternal: delivery cockpit – one-time activity, not a catalogue service\nExternal: ACC-05 – Produce management reporting (Accounting, outside this catalogue set)","tools":"HubSpot","reusableAssets":"Pipeline stage definitions and reporting pattern","typicalEffort":"TBD","typicalDuration":"Continuous","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"The commercial view of the delivery cockpit depends on it","maturity":"1 - Ad hoc","gapsAndRisks":"The account cockpit will require CRM-sourced information on how each account will grow. Whether HubSpot currently holds that at the required quality has not been assessed by anyone","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"}]},{"team":"Asset Extraction","owner":[{"name":"Dominique Deleris","email":null}],"members":"TBD","mission":"Turn work that was done once into something the next engagement can use without rebuilding it.","serves":"Internal – every delivery function, and the product roadmap","engage":"Directly, all along projects delivery as soon as an asset is identified.","leadTime":"Same week","capacity":"Currently constrained by operational load on main client SW.","maturity":"1 - Ad hoc","interviewStatus":"N/A","confirmedOn":"N/A","sourceFile":"Confluence page 468680705","services":[{"id":"AEX-01","name":"Identify reusable assets in delivered work","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Spot the thing that was built once and can be leveraged again beyond the current engagement.","description":"Works through delivered or in-flight engagements and identifies what could be generalised: checklists, matrices, configurations, code modules, documents, methods.","inScope":"Interview-based discovery; review of delivered artefacts; candidate asset identification; first-pass value and effort assessment","outOfScope":"Packaging the asset (AEX-02); the IP position (LEG-03, AEX-05); the technical productisation decision (PRD-01)","trigger":"An engagement reaches a milestone, a new deliverable type is produced, a new engagement type is run for the first time","inputs":"Access to the people who did the work; the delivered artefacts where they exist","keyActivities":["Interview the people who delivered it.","Review what was actually produced.","List candidates.","Assess reuse value against extraction effort.","Prioritise."],"outputs":"Candidate asset list with value and effort assessment; prioritised extraction backlog","definitionOfDone":"Every candidate has a stated value, an effort estimate and a decision to extract or not","consumes":"DEL-01 – Take over an ongoing project\nDEL-03 – Run delivery assurance\nDEV-02 – Build client-specific applications\nDEV-05 – Produce technical documentation\nGap: project closure and handover – no service in the current catalogue owns this","feeds":"AEX-02 – Extract and package an asset\nAEX-05 – Assess productisation and the IP position\nDEL-02 – Define and maintain the delivery method\nPRD-01 – Define and maintain the product vision and roadmap","tools":"Interview + Claude skill","reusableAssets":"The extraction interview guide itself","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"TBD","pricingUnit":"Not applicable","contribution":"Key to streamline efficiency and grow customer base","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 28 August 2026"},{"id":"AEX-02","name":"Extract and package an asset","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Take the client-specific artefact and make it general enough to be reused across clients/industries.","description":"Turns a candidate into a usable asset: strips client-specific content, generalises, documents how and when to use it, and store as a corporate asset.","inScope":"Generalisation and de-identification; documentation of purpose and usage; versioning; publication into the library","outOfScope":"Deciding what to extract (AEX-01); applying it to a new engagement (AEX-04); the legal right to reuse it (LEG-03)","trigger":"A candidate is prioritised for extraction","inputs":"The source artefact; the IP position; access to the person who built it","keyActivities":["Strip client-specific content.","Generalise to the pattern.","Write usage guidance and preconditions.","Version and publish.","Test it on the next engagement."],"outputs":"Packaged asset with usage guidance; library entry; version record","definitionOfDone":"Someone who was not on the source engagement uses it successfully without asking how","consumes":"AEX-01 – Identify reusable assets in delivered work\nAEX-05 – Assess productisation and the IP position\nDEV-05 – Produce technical documentation","feeds":"AEX-03 – Maintain the asset library\nAEX-04 – Reapply an asset to a new engagement\nDEL-02 – Define and maintain the delivery method\nPRD-01 – Define and maintain the product vision and roadmap","tools":"TBD","reusableAssets":"By definition, all of them. Also the packaging method itself","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal","pricingUnit":"N/A","contribution":"Turns delivery experience into something sellable more than once","maturity":"1 - Ad hoc","gapsAndRisks":"No corporate document templates exist, and the brand pack is still in review – which limits how finished a packaged asset can currently look.\nDepends on the IP position, which is unresolved on the two systems most worth extracting from.","status":"Draft – Proposal","versionDate":"v0.1 – 28 August 2026"},{"id":"AEX-03","name":"Maintain the asset library","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Keep the assets findable, current, and honest about their own maturity.","description":"Maintain the catalogue of extracted assets: what exists, what it is for, its version, its maturity, and who has used it. Prevents the usual failure mode where an asset is extracted once and never found again.","inScope":"Asset register; versioning and deprecation; maturity marking; usage tracking; retirement of assets that stopped being true","outOfScope":"Producing the assets (AEX-02); the wider knowledge base and wiki; the service catalogue itself","trigger":"An asset is published, used, or found to be out of date","inputs":"A location; a register format; discipline in recording use","keyActivities":["Register each published asset.","Track versions and usage.","Mark maturity honestly.","Retire what no longer holds."],"outputs":"Asset register; version history; usage record","definitionOfDone":"Someone looking for an asset finds it, and can tell how much to trust it","consumes":"AEX-02 – Extract and package an asset\nAEX-04 – Reapply an asset to a new engagement\nBPX-05 – Maintain the process repository","feeds":"AEX-04 – Reapply an asset to a new engagement\nDEL-02 – Define and maintain the delivery method\nSBD-02 – Produce proposals and offers\nExternal: HR-06 – Map skills and organise training (Human Resources, outside this catalogue set)","tools":"TBD","reusableAssets":"The register structure","typicalEffort":"TBD","typicalDuration":"Continuous","deliveryModel":"Internal","pricingUnit":"N/A","contribution":"Whether extraction compounds or evaporates","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 28 August 2026"},{"id":"AEX-04","name":"Reapply an asset to a new engagement","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Actually use the asset on the next client, and fix what breaks when you do.","description":"The half of extraction that proves the other half worked.","inScope":"Selecting the right asset for the engagement; adapting it to context; capturing what broke; feeding revisions back into the library","outOfScope":"Running the engagement (DEL-07); creating a new asset from scratch (AEX-02)","trigger":"A new engagement of a type an asset already covers","inputs":"The asset library; an engagement to apply it to; the engagement typology","keyActivities":["Select the asset for the engagement type.","Adapt to the client context.","Use it in context.","Record what did not survive contact.","Revise the asset."],"outputs":"Applied asset; adaptation record; revised library version","definitionOfDone":"The asset was used, the revisions are back in the library, and the next person needs less help than the last","consumes":"AEX-02 – Extract and package an asset\nAEX-03 – Maintain the asset library\nDEL-02 – Define and maintain the delivery method\nDEL-04 – Set up a new engagement\nSBD-04 – Maintain client typology and account plans","feeds":"AEX-03 – Maintain the asset library\nDEL-02 – Define and maintain the delivery method\nDEL-04 – Set up a new engagement","tools":"The assets library","reusableAssets":"The adaptation record itself, which is what turns a one-client asset into a typology-level one","typicalEffort":"To complete after the session","typicalDuration":"TBD","deliveryModel":"Internal, applied on billable engagements","pricingUnit":"TBD","contribution":"The economic argument for the whole extraction function","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 28 August 2026"},{"id":"AEX-05","name":"Assess productisation and the IP position","owner":[{"name":"Fabien Delalondre","email":null}],"purpose":"Decide whether something built for one client can legally and technically be sold to another.","description":"For assets with commercial potential, establishes two things: whether the thing is technically generalisable, and whether Twym has the right to reuse it.","inScope":"Technical generalisability assessment; market applicability; the IP and contractual position; recommendation to productise, reuse internally, or leave client-specific","outOfScope":"Negotiating the IP rights (LEG-03); building the product (DEV-01); pricing it (SBD-02)","trigger":"An asset shows commercial potential, or a client asks for something Twym has already built elsewhere","inputs":"The technical assessment from the people who built it; the client contract; a commercial view of the market","keyActivities":["Assess technical generalisability with the build team.","Establish the contractual and IP position.","Assess market applicability.","Recommend.","Record the position so it is not reassessed from scratch later."],"outputs":"Productisation assessment; IP position per asset; recommendation","definitionOfDone":"The asset has a written position on whether it can be reused, and on what basis","consumes":"AEX-01 – Identify reusable assets in delivered work\nDEV-02 – Build client-specific applications\nPRD-05 – Run market and opportunity research","feeds":"AEX-02 – Extract and package an asset\nPRD-01 – Define and maintain the product vision and roadmap\nSBD-02 – Produce proposals and offers","tools":"TBD","reusableAssets":"TBD","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal","pricingUnit":"N/A","contribution":"Determines which client builds become products, which is the difference between a consultancy and a product company","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 28 August 2026"}]},{"team":"Delivery","owner":[{"name":"Dominique Deleris","email":null}],"members":"Dominique Deleris, Cédric Templie","mission":"Make delivery repeatable: run engagements, extract what worked, and turn it into something the next engagement can use without the same person running it.","serves":"Both – client engagements and the internal teams whose method this function builds","engage":"Directly","leadTime":"Same week","capacity":"TBD","maturity":"1 - Ad hoc","interviewStatus":"","confirmedOn":"","sourceFile":"Confluence page 468582402","services":[{"id":"DEL-01","name":"Take over an ongoing project","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Walk into a running project, whether the handover is planned or the project is drifting, and give it a structure it can be delivered from.","description":"Take over a project already in motion – whether the trigger is a drifting delivery or a planned change of delivery lead – work out what is really happening, restructure scope, cost and time, and leave it running to a plan.","inScope":"Situation assessment through interviews; scope, cost and time restructuring; governance reset; risk surfacing; a plan the team can work to","outOfScope":"Ongoing execution once restructured and stable (DEL-07); ongoing project management and status reporting (PM-02); technical remediation (TL-05); commercial renegotiation (SBD-02, LEG-01)","trigger":"A project is drifting, a delivery lead changes, or delivery ownership is deliberately transferred and needs a fresh structural baseline","inputs":"Access to the people running it; sponsor mandate to change the plan","keyActivities":["Interview everyone with a stake (use MM agent).","Reconstruct actual status against intended status.","Restructure scope, cost and time.","Reset governance.","Hand back to a named owner with a plan."],"outputs":"Situation assessment; restructured plan with scope, cost and time; risk list; governance reset","definitionOfDone":"A named owner is running the project to the new plan, and the sponsor has accepted the restructure","consumes":"DEL-02 – Define and maintain the delivery method\nDEL-03 – Run delivery assurance","feeds":"AEX-01 – Identify reusable assets in delivered work\nDEL-02 – Define and maintain the delivery method\nDEL-03 – Run delivery assurance\nDEL-07 – Run customer delivery","tools":"Interview and MM format supported by skill/agent. Playbook v1 in draft","reusableAssets":"The takeover playbook itself, which doubles as the handover pack when a delivery lead changes","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"TBD","pricingUnit":"TBD","contribution":"The recovery and restructuring offer, and the pilot engagement template","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.2 – 2 September 2026","playbook":{"version":"0.5","versionDate":"2026-09-11","status":"Draft – pending peer review and CEO approval"}},{"id":"DEL-02","name":"Define and maintain the delivery method","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Write down how Twym delivers, so the next engagement does not start from a blank page.","description":"Produces the playbooks, checklists and templates that constitute Twym's delivery method, per engagement type.","inScope":"Playbooks per engagement type; checklists; templates; the method's own review cycle; engagement-type typology in delivery terms; delivery best-practice monitoring","outOfScope":"Business process definition for other functions (BPX-02); extracting assets from a specific engagement (AEX-02); the commercial typology and growth playbook (SBD-04, DEL-06)","trigger":"An engagement type has been run at least once and is about to be run again","inputs":"TBD","keyActivities":["Capture how it was actually done.","Draft the playbook and checklist.","Apply it on the next engagement.","Revise from what broke.","Repeat until it runs without me.","Monitor delivery best practice, and fold relevant insight into the method."],"outputs":"Playbook per engagement type; checklists; document and deliverable templates","definitionOfDone":"Someone else runs the process from the playbook without supervision","consumes":"AEX-01 – Identify reusable assets in delivered work\nAEX-02 – Extract and package an asset\nAEX-03 – Maintain the asset library\nAEX-04 – Reapply an asset to a new engagement\nDEL-01 – Take over an ongoing project\nDEL-03 – Run delivery assurance\nSBD-06 – Own positioning, brand and pricing strategy","feeds":"AEX-04 – Reapply an asset to a new engagement\nDEL-01 – Take over an ongoing project\nDEL-04 – Set up a new engagement\nDEL-05 – Hand over to a delivery lead\nDEL-06 – Build and run the account growth playbook\nDEL-07 – Run customer delivery\nDEL-10 – Select regional delivery partners\nSBD-02 – Produce proposals and offers","tools":"TBD","reusableAssets":"This is the asset-producing service. Everything it makes is by definition reusable","typicalEffort":"TBD","typicalDuration":"Continuous, weekly iteration","deliveryModel":"Internal","pricingUnit":"Not applicable directly. Reduces the cost of every engagement priced afterwards","contribution":"Sequential asset strategy: build on a transformation engagement, rebuild for a professional services and outsourcing engagement, distinct template for pilot engagements","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.2 – 2 September 2026"},{"id":"DEL-03","name":"Run delivery assurance","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Check that what Twym is about to hand a client holds together, whoever built it.","description":"Independent review of an engagement against what was promised: coherence of the deliverable, state of the documentation, risks nobody has raised, and whether the client can actually operate what they are being given.","inScope":"Pre-handover review; risk challenge; readiness assessment against the promise made","outOfScope":"Functional testing (QA-03); technical review (TL-03); running the project (PM-02)","trigger":"A go-live, a handover, or a delivery that has gone quiet","inputs":"The commitment made to the client; access to the deliverable and the team","keyActivities":["Establish what was promised.","Review the deliverable and its documentation against it.","Challenge open risks.","State readiness plainly.","Track what has to be fixed before handover."],"outputs":"Assurance review note; readiness position; list of items to fix before handover","definitionOfDone":"The review is on record and either the gaps are closed or someone has accepted them by name","consumes":"DEL-01 – Take over an ongoing project\nDEL-07 – Run customer delivery\nDEL-08 – Manage vendor delivery performance\nDEL-09 – Ensure delivery compliance and data residency\nDEV-05 – Produce technical documentation\nQA-01 – Requirement Quality Review\nQA-08 – Release Readiness\nQA-12 – Quality Analytics\nTL-05 – Manage technical risk and technical debt","feeds":"AEX-01 – Identify reusable assets in delivered work\nBA-04 – Support acceptance and user validation\nDEL-01 – Take over an ongoing project\nDEL-02 – Define and maintain the delivery method\nPRD-02 – Capture and triage feature requests\nGap: project closure and handover – no service in the current catalogue owns this","tools":"Assurance checklist","reusableAssets":"Assurance checklist per engagement type; readiness criteria","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"TBD","pricingUnit":"TBD","contribution":"Reputational protection.","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.2 – 2 September 2026"},{"id":"DEL-04","name":"Set up a new engagement","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Start an engagement from the method rather than from improvisation.","description":"Applies the playbook for the relevant engagement type to a newly signed client: governance, team, tooling, reporting, and the delivery approach.","inScope":"Engagement type selection; playbook application; governance and reporting set-up; delivery team shape; client onboarding into Twym's way of working","outOfScope":"The commercial close (SBD-02); contracting (LEG-01); project-level set-up within the engagement (PM-01)","trigger":"An offer is signed, or a pilot is agreed","inputs":"Signed offer; engagement type identified; the corresponding playbook","keyActivities":["Classify the engagement type.","Apply the matching playbook.","Set up governance and reporting.","Shape the delivery team.","Run the first cycle and revise the playbook from it."],"outputs":"Engagement set-up pack; governance calendar; reporting structure","definitionOfDone":"The first governance cycle runs to plan and the client knows how the engagement will be run","consumes":"AEX-04 – Reapply an asset to a new engagement\nDEL-02 – Define and maintain the delivery method\nDEL-05 – Hand over to a delivery lead\nDEL-10 – Select regional delivery partners\nSBD-02 – Produce proposals and offers\nSBD-04 – Maintain client typology and account plans","feeds":"AEX-04 – Reapply an asset to a new engagement\nDEL-06 – Build and run the account growth playbook\nDEL-09 – Ensure delivery compliance and data residency\nSBD-02 – Produce proposals and offers\nExternal: delivery cockpit – one-time activity, not a catalogue service","tools":"Playbooks per engagement type","reusableAssets":"Engagement set-up pack per typology","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"TBD","pricingUnit":"TBD","contribution":"How every new client experiences Twym in the first fortnight","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"DEL-05","name":"Hand over to a delivery lead","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Change who runs an engagement without losing what they knew.","description":"Transfers an engagement between delivery leads: context, relationships, commitments, risks and the state of everything in flight.","inScope":"Handover pack assembly; relationship and commitment transfer; risk and decision briefing; shadowing period","outOfScope":"Project-level closure and handover to run (PM-06); HR aspects of a leaver (HR-01)","trigger":"A delivery lead changes, leaves, or takes on a second engagement","inputs":"Current engagement documentation; the outgoing lead's availability; the playbook","keyActivities":["Assemble the handover pack from the playbook.","Brief on commitments, relationships and risks.","Shadow through one governance cycle.","Transfer named ownership."],"outputs":"Handover pack; commitment and relationship list; transfer record","definitionOfDone":"The incoming lead runs a full governance cycle unaided","consumes":"DEL-02 – Define and maintain the delivery method","feeds":"DEL-04 – Set up a new engagement","tools":"The playbook, doubling as the handover pack","reusableAssets":"Handover pack structure","typicalEffort":"TBD","typicalDuration":"One governance cycle of shadowing","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"Continuity, which matters more as the regional partner model spreads delivery across countries","maturity":"1 - Ad hoc","gapsAndRisks":"Untested. No handover has been observed","status":"Draft – Proposal","versionDate":"v0.1 – 24 August 2026"},{"id":"DEL-06","name":"Build and run the account growth playbook","owner":[{"name":"Dominique Deleris","email":null},{"name":"Fabien Clerc","email":null}],"purpose":"Treat account growth as a part of delivery rather than as something sales does afterwards.","description":"Defines how an engagement is grown from inside delivery – spotting adjacent needs, converting delivery credibility into scope, and feeding the commercial side.","inScope":"Growth playbook per engagement type; opportunity identification from inside delivery; handoff into the commercial process; account growth reporting into the cockpit; pre-sales input on scoping and estimating during the sales cycle; delivery feedback to Product Management on product and platform evolution","outOfScope":"Owning the commercial relationship and closing (SBD-01, SBD-02); pricing (SBD-02)","trigger":"An engagement is running steadily enough to look beyond it, or a typology review","inputs":"Engagement typology; CRM data on the account; delivery-side visibility of the client's wider estate","keyActivities":["Define what growth means for this engagement type.","Identify adjacent needs from delivery contact.","Qualify and hand to the commercial side.","Track conversion.","Revise the playbook from what converted.","Provide pre-sales input on scoping and estimating when asked.","Feed delivery insight back to Product Management on product and platform evolution."],"outputs":"Growth playbook per typology; qualified opportunity handoffs; conversion tracking","definitionOfDone":"The playbook has produced at least one qualified opportunity that the commercial side accepted","consumes":"DEL-02 – Define and maintain the delivery method\nDEL-04 – Set up a new engagement\nSBD-04 – Maintain client typology and account plans\nSBD-07 – Maintain the CRM and pipeline reporting\nExternal: delivery cockpit – one-time activity, not a catalogue service","feeds":"SBD-01 – Qualify and develop opportunities\nExternal: delivery cockpit – one-time activity, not a catalogue service","tools":"TwymSense, HubSpot for the commercial side. No growth playbook exists","reusableAssets":"Growth playbook per typology – transformation, professional services and outsourcing, pilot","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Internal, in support of billable growth","pricingUnit":"Not applicable","contribution":"Turning the current accounts into a repeatable account development motion","maturity":"1 - Ad hoc","gapsAndRisks":"Overlaps Sales & Business Development, and the split has not been agreed.","status":"Draft – Proposal","versionDate":"v0.2 – 2 September 2026"},{"id":"DEL-07","name":"Run customer delivery","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Run an engagement's day-to-day execution against an approved roadmap, from task breakdown to acceptance, without waiting for a takeover trigger.","description":"Translates an approved roadmap into phases, workstreams, milestones, deliverables, dependencies and acceptance criteria; decomposes it into tasks allocated across client, Twym and vendor resources; and manages day-to-day execution to protect completeness, quality and adoption readiness. Includes validating delivery against acceptance criteria, requiring rework where needed, and the authority to suspend execution activities pending governance review when security, compliance or delivery integrity is at material risk.","inScope":"Roadmap-to-phase/milestone/deliverable/dependency/acceptance-criteria translation; task decomposition and allocation; day-to-day execution management across client, Twym and vendor teams; quality-gate validation and rework decisions; authority to suspend execution on material risk; senior review and guidance of PM and BA outputs; structured client feedback collection (check-ins, post-milestone and post-phase reviews)","outOfScope":"Taking over a project that is drifting, which starts from a restructuring baseline (DEL-01); project governance forums and status reporting (PM-02); technical review (TL-03); vendor performance management as a standing discipline (DEL-08)","trigger":"An engagement has an approved roadmap and enters or continues execution","inputs":"Approved roadmap and architecture; a resourced delivery team; defined acceptance criteria","keyActivities":["Translate the approved roadmap into phases, milestones, deliverables, dependencies and acceptance criteria.","Decompose into tasks and allocate to internal and external resources.","Manage day-to-day execution across client, Twym and vendor teams.","Validate delivery completeness and quality at each gate, requiring rework where needed.","Review PM and BA outputs and collect structured client feedback."],"outputs":"Execution plan with phases, milestones and acceptance criteria; task allocation; quality-gate decisions; client feedback record","definitionOfDone":"Each milestone is accepted against its criteria and the client's feedback on it is on record","consumes":"DEL-01 – Take over an ongoing project\nDEL-02 – Define and maintain the delivery method\nDEL-09 – Ensure delivery compliance and data residency","feeds":"DEL-03 – Run delivery assurance\nDEL-08 – Manage vendor delivery performance\nExternal: delivery cockpit – one-time activity, not a catalogue service","tools":"TBD","reusableAssets":"Execution plan template; quality-gate checklist","typicalEffort":"TBD","typicalDuration":"Continuous for the life of the engagement","deliveryModel":"Billable to client","pricingUnit":"TBD","contribution":"The execution backbone of the transformation delivery offer, and the evidence base the contract's own KPIs (timeliness, budget adherence, deviation reporting) will be measured against","maturity":"1 - Ad hoc","gapsAndRisks":"Boundary with PM not yet agreed - tasks breakdown, daily followup, etc... (cf. In scope and Key activities)","status":"Draft – Proposal","versionDate":"v0.1 – 2 September 2026"},{"id":"DEL-08","name":"Manage vendor delivery performance","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Keep vendor delivery on time, on budget and at the required quality, and act early when it isn't.","description":"Ongoing management of vendor delivery performance across an engagement, distinct from DEL-03's point-in-time pre-handover review. Covers performance tracking against commitments, corrective action, vendor engagement optimisation to protect margins and outcomes, and support for vendor selection or transition where required.","inScope":"Vendor performance tracking against delivery commitments; corrective action and escalation on underperformance; vendor engagement optimisation for outcome, margin and relationship; support for vendor selection or transition","outOfScope":"Pre-handover assurance review (DEL-03); commercial negotiation and contracting with vendors (SBD, LEG-01); day-to-day task allocation to vendor resources (DEL-07)","trigger":"A vendor is engaged on a live engagement; standing for the life of that engagement","inputs":"Vendor commitments and SLAs; a named vendor contact; visibility of vendor output","keyActivities":["Track vendor delivery against commitments.","Flag underperformance early.","Agree and follow up corrective action.","Optimise the engagement for outcome and margin.","Support vendor selection or transition when needed."],"outputs":"Vendor performance record; corrective action log; selection or transition support notes","definitionOfDone":"Every tracked vendor commitment has a current status, and underperformance has a named corrective action","consumes":"DEL-07 – Run customer delivery","feeds":"DEL-03 – Run delivery assurance","tools":"TBD","reusableAssets":"Vendor performance tracker template","typicalEffort":"TBD","typicalDuration":"Continuous for the life of the vendor engagement","deliveryModel":"Both","pricingUnit":"Not applicable","contribution":"Protects margin and outcome on any engagement using external vendors","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 2 September 2026"},{"id":"DEL-09","name":"Ensure delivery compliance and data residency","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Keep execution activity inside client and Twym policy, and inside data-residency and cross-border restrictions where a client is regulated.","description":"Ensures execution activities comply with applicable client and Twym policies, and – for clients in regulated industries – with data-residency and cross-border access restrictions on client systems and data.","inScope":"Mapping applicable client and Twym policy requirements per engagement; identifying regulated-industry restrictions on data residency and cross-border access at engagement start; escalating ambiguity before acting; incident reporting for actual or suspected breaches","outOfScope":"Twym's group-level cloud and data-hosting position (G-06, owner Fabien); contractual data-protection terms (LEG); technical security controls (TL, Security)","trigger":"A new engagement is set up, or a client is identified as operating in a regulated industry","inputs":"Client policy requirements; contractual data-residency terms; Twym's own policy position, which depends on G-06 where unresolved","keyActivities":["Map applicable client and Twym policy requirements at engagement start.","Identify regulated-industry restrictions on data and cross-border access.","Escalate ambiguity before acting.","Report actual or suspected breaches immediately."],"outputs":"Engagement compliance and data-residency position; breach or incident reports where applicable","definitionOfDone":"The engagement's compliance and data-residency position is documented and confirmed with the client","consumes":"DEL-04 – Set up a new engagement\nExternal: LEG – contract terms from the Legal catalogue","feeds":"DEL-03 – Run delivery assurance\nDEL-07 – Run customer delivery","tools":"TBD","reusableAssets":"Engagement compliance checklist","typicalEffort":"TBD","typicalDuration":"Set at engagement start, reviewed periodically","deliveryModel":"Billable to client, for regulated engagements","pricingUnit":"Not applicable","contribution":"Required for any regulated-industry client","maturity":"1 - Ad hoc","gapsAndRisks":"TBD","status":"Draft – Proposal","versionDate":"v0.1 – 2 September 2026"},{"id":"DEL-10","name":"Select regional delivery partners","owner":[{"name":"Dominique Deleris","email":null}],"purpose":"Choose local delivery partners that work to Twym's method and do not compete with Twym, before Twym opens an office in a new country.","description":"Runs the Partner Selection Playbook for one location: sourcing and pre-screen, Introduction session and conflict screen, Delivery capabilities assessment, practical test, due diligence and references, then Delivery's recommendation to the CEO, who approves the partner selection. After approval Delivery steps in again only for a formal reassessment triggered by new evidence. Delivery leads. Sales provides the location brief and is consulted on rates; Operations orders the country legal and tax opinion and runs the sanctions re-screen.","inScope":"Long-list and pre-screen; Introduction session, conflict checks and Gate 0; assessment and practical test; due diligence and reference checks; evidence records; panel recommendation to the CEO; feedback to unsuccessful firms; playbook upkeep after each location","outOfScope":"Location brief, day-rate ceiling and partner proposition (SBD-05); contracting, onboarding and governance of a selected partner (OPW-05, OPE-05); supplier contracting terms (LEG-02); vendor performance on a live engagement (DEL-08)","trigger":"The CEO approves a location brief","inputs":"Approved location brief; country legal and tax opinion ordered; panel availability","keyActivities":["Source and pre-screen firms.","Run the Introduction session and the conflict screen.","Assess delivery capabilities and run the practical test.","Carry out due diligence and reference calls.","Record the decision for the CEO's approval."],"outputs":"An evidence-backed recommendation for CEO approval of delivery partner(s), including permitted delivery model, scope, location, risk tier, conditions and named delivery leads (the decision record), with the pipeline tracker, conflict screen records and scorecards behind it","definitionOfDone":"The CEO has decided on the recommendation and every unsuccessful firm has had feedback","consumes":"DEL-02 – Define and maintain the delivery method\nSBD-05 – Define regional partner demand and proposition","feeds":"DEL-04 – Set up a new engagement\nExternal: OPW-05 – Manage suppliers and delivery partners (Operations West, outside this catalogue set)\nExternal: OPE-05 – Manage suppliers and delivery partners (Operations East, outside this catalogue set)","tools":"Partner Selection Playbook (location brief, assessment guide, practical test pack, decision record)","reusableAssets":"The playbook and its annexes; pipeline tracker; lessons from each location","typicalEffort":"About 15 panel person-hours per firm through the test (Twym proposal)","typicalDuration":"10 weeks per location, 11 with a buffer week (Twym proposal)","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"Geographic expansion without carrying the fixed cost of an office","maturity":"3 - Documented","gapsAndRisks":"Documented in the Partner Selection Playbook but not yet run for any location. Time-boxes and effort figures are Twym proposals to recalibrate after the first location. The sign-off by Fabien Delalondre is pending","status":"Draft – Proposal","versionDate":"v0.2 – 2 October 2026"}]},{"team":"Quality Assurance","owner":[{"name":"Vidhi Vinchhi","email":null}],"members":"Vidhi Vinchhi (QA Lead), Krunal Patel (Sr. QA)","mission":"Establish a consistent, measurable, and scalable QA practice that delivers reliable, high-quality software through early validation, risk-based testing, automation, and continuous improvement.","serves":"Both – internal products and client-delivered systems","engage":"To confirm. No path described yet.","leadTime":"To confirm","capacity":"Use risk-based prioritization, capacity planning, and progressive automation. Where demand exceeds capacity, align on resource, scope, or timeline adjustments.","maturity":"2 - Repeatable","interviewStatus":"","confirmedOn":"","sourceFile":"Confluence page 461242371","services":[{"id":"QA-01","name":"Requirement Quality Review","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Reduce ambiguity and rework before implementation.","description":"Reviews requirements and acceptance criteria for clarity, completeness, testability and risk before development commits effort. Surfaces gaps, contradictions and untestable statements so they are fixed early rather than discovered in validation.","inScope":"Requirement and acceptance-criteria review; testability assessment; gap and ambiguity logging; feedback to BA/Product","outOfScope":"Writing the requirements themselves (BA/PRD); test execution (QA-03); design QA (UX)","trigger":"Requirements or a feature specification is ready for review, or a quality gate for requirements opens","inputs":"Draft requirements / user stories / acceptance criteria; business context; known constraints","keyActivities":["Review requirements for clarity and completeness.","Check acceptance criteria for testability.","Record gaps, ambiguities and risks.","Feed findings back to BA/Product.","Confirm readiness for development."],"outputs":"Requirement review notes; gap list; testability risks","definitionOfDone":"Requirements in scope have been reviewed and open gaps are owned before build starts","consumes":"BA-01 – Elicit and document requirements\nBA-02 – Write user stories and acceptance criteria\nPRD-03 – Specify a feature for build","feeds":"DEL-03 – Run delivery assurance\nQA-02 – Risk & Test Planning\nQA-03 – Functional Validation\nQA-11 – AI-Assisted QA\nQA-13 – AI Product / Software QA","tools":"Confluence, Jira, Word/Excel,Cursor","reusableAssets":"Requirement review checklist; testability criteria","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Lower rework and clearer fixed-price commitments","maturity":"2 - Repeatable","gapsAndRisks":"Strategy current state: QA may learn requirements after implementation is underway","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-02","name":"Risk & Test Planning","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Match QA depth to business and technical risk.","description":"Produces the risk assessment, test scope and test approach for an engagement or release so effort is proportionate: what will be tested, to what depth, in which environments, by whom, and against which exit criteria.","inScope":"Risk assessment; test scope and levels; approach; environment needs; roles; entry/exit criteria","outOfScope":"Building environments (TL); executing tests (QA-03); commercial acceptance criteria ownership (BA)","trigger":"An engagement, major feature set or release planning cycle starts","inputs":"Requirements position; known risks; delivery cadence; environment status","keyActivities":["Identify business and technical risks.","Define test scope and depth.","Agree approach, environments and roles.","Set entry/exit criteria.","Confirm plan with the project."],"outputs":"Risk assessment; test scope; test approach","definitionOfDone":"Project has an agreed QA plan and risk-based scope before significant build/test effort","consumes":"BA-01 – Elicit and document requirements\nBA-03 – Produce functional specifications\nQA-01 – Requirement Quality Review\nTL-02 – Set and enforce technical standards\nTL-04 – Own environments and the deployment approach","feeds":"QA-03 – Functional Validation\nQA-04 – API / Backend Validation\nQA-05 – Regression Protection\nQA-06 – Data Validation\nQA-07 – Performance / Resilience Testing\nQA-08 – Release Readiness\nQA-13 – AI Product / Software QA","tools":"Excel,JIRA,Cursor","reusableAssets":"Risk/test planning template; playbook selection inputs","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Credible estimation of QA cost versus risk","maturity":"2 - Repeatable","gapsAndRisks":"Strategy: testing types may be selected per project, but a common playbook framework is not yet formalized","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-03","name":"Functional Validation","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Confirm business behaviour meets agreed expectations.","description":"Designs and executes functional scenarios against a testable build, records evidence, raises defects and re-tests fixes. Covers agreed functional paths for internal products and client-delivered systems.","inScope":"Scenario design; functional execution; defect raising; re-test; evidence capture","outOfScope":"API/contract focus (QA-04); performance/resilience (QA-07); design conformance (UX); client UAT ownership (BA)","trigger":"A build reaches a testable state against an agreed scope","inputs":"Test approach; acceptance criteria; deployed build; test data","keyActivities":["Confirm build and scope are testable.","Execute functional scenarios.","Record results and raise defects.","Re-test after fixes.","Hand evidence into release readiness."],"outputs":"Executed scenarios; defects; test evidence","definitionOfDone":"Agreed functional scope has recorded results and open failures are logged as defects","consumes":"BA-02 – Write user stories and acceptance criteria\nDEV-01 – Build product features\nDEV-02 – Build client-specific applications\nDEV-03 – Integrate third-party and client systems\nDEV-04 – Fix defects and provide third-line support\nDEV-06 – Release to production\nMOB-01 – Build mobile features from designs\nPRD-03 – Specify a feature for build\nPRD-04 – Agree the weekly delivery scope\nQA-01 – Requirement Quality Review\nQA-02 – Risk & Test Planning\nTL-04 – Own environments and the deployment approach","feeds":"DEV-04 – Fix defects and provide third-line support\nMOB-03 – Mobile testing and device coverage\nQA-05 – Regression Protection\nQA-08 – Release Readiness\nQA-11 – AI-Assisted QA\nQA-12 – Quality Analytics","tools":"JIRA","reusableAssets":"Scenario patterns; evidence pack format","typicalEffort":"TBD","typicalDuration":"Per sprint / delivery window","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Evidence that delivered behaviour matches what was agreed","maturity":"3 - Documented","gapsAndRisks":"Strategy: QA can be brought in after development declares functionality ready – becomes downstream validation rather than prevention","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-04","name":"API / Backend Validation","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Validate service contracts, business rules and integrations.","description":"Checks APIs, backend rules and integrations against contracts and expected business behaviour: request/response, error handling, data rules and integration points that UI testing alone will miss.","inScope":"API/contract checks; backend business-rule validation; integration checks; related defects","outOfScope":"Unit tests owned by development; infrastructure provisioning; full performance load (QA-07)","trigger":"API or backend change is ready for validation, or integration risk is in scope for the playbook","inputs":"API specs/contracts; environments; test data; auth/test credentials","keyActivities":["Identify contracts and critical backend rules.","Design API/integration checks.","Execute and compare to expected behaviour.","Log contract/data failures.","Re-test after fixes."],"outputs":"API checks; data validations; defects","definitionOfDone":"In-scope contracts and backend rules have recorded results","consumes":"DEV-01 – Build product features\nQA-02 – Risk & Test Planning\nTL-02 – Set and enforce technical standards","feeds":"DEV-04 – Fix defects and provide third-line support\nQA-06 – Data Validation\nQA-08 – Release Readiness","tools":"Postman","reusableAssets":"API check patterns; contract validation checklist","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Protects integrations that clients and products depend on","maturity":"3 - Documented","gapsAndRisks":"Strategy capability baseline for API/Backend still to be established","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-05","name":"Regression Protection","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Prevent existing functionality from breaking.","description":"Maintains and runs the regression set (manual and/or automated) so changes do not silently break previously working behaviour across the product estate.","inScope":"Regression set curation; regression execution; result reporting; feedback into automation (QA-10)","outOfScope":"New-feature functional deep-dive (QA-03); building the automation framework itself except selecting candidates (QA-10)","trigger":"Each release candidate or significant merge where prior behaviour must still hold","inputs":"Prior test assets; known critical paths; stable environment","keyActivities":["Maintain the regression set.","Select what runs for this release.","Execute regression.","Triage failures.","Report pass rate and escaped-risk signal."],"outputs":"Regression suite/results","definitionOfDone":"Agreed regression scope has been run and failures are understood before release","consumes":"QA-02 – Risk & Test Planning\nQA-03 – Functional Validation\nQA-10 – Test Automation","feeds":"QA-08 – Release Readiness\nQA-10 – Test Automation","tools":"Manual/Automated Regression test suit,JIRA","reusableAssets":"Regression packs per product","typicalEffort":"TBD","typicalDuration":"Per release","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Delivery speed without sacrificing what already works","maturity":"3 - Documented","gapsAndRisks":"Strategy: automation expected to scale regression; baseline and target still to be established","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-06","name":"Data Validation","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Protect data integrity and reporting correctness.","description":"Validates data rules, migrations, reconciliations and reporting outputs so business decisions are not made on wrong or incomplete data.","inScope":"Data checks; reconciliation; reporting correctness; related defects","outOfScope":"Owning production data platforms; GDPR/legal advice; fabricating production personal data for tests","trigger":"Data-sensitive change, migration, reporting change, or playbook marks data risk in scope","inputs":"Data rules; sample/safe test data; access to relevant stores or extracts","keyActivities":["Identify critical data rules and reports.","Design checks and reconciliations.","Execute against agreed data sets.","Log integrity failures.","Confirm fix evidence."],"outputs":"Data checks; reconciliation evidence","definitionOfDone":"In-scope data/reporting checks have recorded results","consumes":"QA-02 – Risk & Test Planning\nQA-04 – API / Backend Validation","feeds":"QA-08 – Release Readiness\nQA-12 – Quality Analytics","tools":"DBeaver, Azure Data Studio, SQL Server Management Studio","reusableAssets":"Reconciliation checklists; data-rule patterns","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Trust in numbers clients and operations rely on","maturity":"3 - Documented","gapsAndRisks":"Strategy capability baseline for SQL/Data still to be established; personal-data constraints on law-firm systems","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-07","name":"Performance / Resilience Testing","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Identify non-functional risks before production where required.","description":"Risk-based performance and resilience checks (load, response, failure modes, recovery) when the playbook or business risk requires them—not every project by default.","inScope":"Performance/resilience scenarios; SLA/SLO-oriented checks; failure-mode tests where agreed","outOfScope":"Continuous production monitoring owned by Ops; unconstrained load testing without a risk trigger","trigger":"Playbook or risk assessment marks non-functional risk as in scope","inputs":"Non-functional targets; suitable environment; tooling/access","keyActivities":["Confirm NFRs and risk trigger.","Design performance/resilience scenarios.","Execute in a suitable environment.","Compare to targets.","Report residual risk."],"outputs":"Performance/resilience results","definitionOfDone":"Agreed non-functional checks are executed and results feed the release decision","consumes":"QA-02 – Risk & Test Planning\nTL-04 – Own environments and the deployment approach","feeds":"QA-08 – Release Readiness","tools":"Apache JMeter,LoadRunner,BlazeMeter","reusableAssets":"NFR check patterns; resilience scenario library","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Avoids production surprises on critical journeys","maturity":"2 - Repeatable","gapsAndRisks":"Strategy target: risk-based specialist capability; current baseline to establish","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-08","name":"Release Readiness","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Provide objective evidence for release decisions.","description":"Consolidates test evidence, open defects and residual risks into a readiness position with a clear recommendation: GO, GO WITH RISK, or NO-GO. Informs delivery assurance; does not replace the project/client decision.","inScope":"Readiness assessment; open-defect summary; residual risk; recommendation","outOfScope":"Taking the commercial/go-live decision; performing the deployment","trigger":"A release or go-live decision approaches","inputs":"Results from QA-03–QA-07/QA-09 as in scope; defect view; exit criteria from QA-02","keyActivities":["Consolidate evidence against exit criteria.","Summarise open defects by severity.","State residual risk.","Recommend GO / GO WITH RISK / NO-GO.","Brief decision-makers."],"outputs":"Readiness assessment; risks; GO / GO WITH RISK / NO-GO","definitionOfDone":"Decision-makers have the assessment before they decide","consumes":"MOB-03 – Mobile testing and device coverage\nQA-02 – Risk & Test Planning\nQA-03 – Functional Validation\nQA-04 – API / Backend Validation\nQA-05 – Regression Protection\nQA-06 – Data Validation\nQA-07 – Performance / Resilience Testing\nQA-09 – Production Validation\nQA-10 – Test Automation\nQA-11 – AI-Assisted QA\nQA-13 – AI Product / Software QA","feeds":"BA-04 – Support acceptance and user validation\nDEL-03 – Run delivery assurance\nDEV-06 – Release to production\nMOB-02 – Manage app releases and distribution\nQA-09 – Production Validation\nQA-12 – Quality Analytics","tools":"Jira, Confluence, Release readiness template (Appendix C in strategy)","reusableAssets":"Readiness checklist; decision states","typicalEffort":"TBD","typicalDuration":"TBD","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Protects reputational exposure on what Twym hands over","maturity":"2 - Repeatable","gapsAndRisks":"Strategy: standardized quality gates still being established","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-09","name":"Production Validation","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Confirm expected behaviour after release.","description":"Runs agreed smoke/validation checks after release to confirm critical paths work in the live (or live-like) environment and to catch deployment or config failures early.","inScope":"Post-release smoke/validation; evidence capture; fast defect raise on release failure","outOfScope":"Service-desk incident ownership (OPS); full regression in production","trigger":"A release has been deployed or a go-live window opens","inputs":"Release package; production validation plan; access/monitoring as agreed","keyActivities":["Confirm production validation plan.","Execute smoke/critical checks.","Record evidence.","Raise/escalate failures immediately.","Confirm outcome for handover."],"outputs":"Smoke/validation evidence","definitionOfDone":"Agreed post-release checks are complete and failures are visible","consumes":"DEV-06 – Release to production\nQA-08 – Release Readiness","feeds":"DEV-04 – Fix defects and provide third-line support\nQA-08 – Release Readiness\nQA-12 – Quality Analytics\nExternal: OPS-01 – Design and implement a service desk (Operations, outside this catalogue set)","tools":"JIRA","reusableAssets":"Production smoke packs per product","typicalEffort":"TBD","typicalDuration":"Release day / hypercare window","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Shortens time-to-detect after go-live","maturity":"2 - Repeatable","gapsAndRisks":"To confirm per engagement (environment and access)","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-10","name":"Test Automation","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Reduce repeatable manual effort and improve repeatability.","description":"Builds and maintains automated suites and pipeline hooks for high-value regression and repeatable checks so quality can scale without linear growth in manual effort.","inScope":"Automation design; suite build/maintenance; CI/CD integration where available; suite health","outOfScope":"Unit tests owned by developers; one-off exploratory testing","trigger":"Regression set is stable enough to automate, or strategy roadmap funds automation","inputs":"Stable scenarios; testable environment; tooling standards","keyActivities":["Select high-value cases to automate.","Build/maintain automation.","Integrate into pipeline where possible.","Manage flakiness.","Report effort avoided and stability."],"outputs":"Automated suites and pipelines","definitionOfDone":"Suite runs on the agreed cadence and failures are trusted","consumes":"QA-05 – Regression Protection\nTL-02 – Set and enforce technical standards\nTL-04 – Own environments and the deployment approach","feeds":"QA-05 – Regression Protection\nQA-08 – Release Readiness\nQA-11 – AI-Assisted QA","tools":"Playwright,Cursor,Jmeter","reusableAssets":"Shared automation framework; suite packs","typicalEffort":"TBD","typicalDuration":"Ongoing build-up","deliveryModel":"Internal (primarily)","pricingUnit":"Not always separately priced","contribution":"Scalability of a one-week delivery cadence across products","maturity":"2 - Repeatable","gapsAndRisks":"Strategy: automation baseline and target to establish; CI/CD capability to baseline","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-11","name":"AI-Assisted QA","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Increase QA productivity while retaining human quality control.","description":"Uses AI to assist analysis, generation and evidence drafting (requirements gaps, scenarios, automation assistance, defect clustering, reporting drafts) with mandatory human review before anything becomes a quality decision.","inScope":"AI-assisted analysis/generation; controlled pilots; human review gates","outOfScope":"Unreviewed AI output as release evidence; replacing QA ownership of decisions","trigger":"Approved use-case pilot or standard operating step where AI assistance is allowed","inputs":"Clear use case; human reviewer; data/privacy constraints understood","keyActivities":["Select approved AI use case.","Generate draft analysis/assets.","Human review and edit.","Apply only accepted outputs.","Measure time saved and review rate."],"outputs":"AI-assisted analysis / generation / evidence (human-approved)","definitionOfDone":"AI outputs used in delivery have a named human reviewer","consumes":"QA-01 – Requirement Quality Review\nQA-03 – Functional Validation\nQA-10 – Test Automation","feeds":"QA-08 – Release Readiness\nQA-12 – Quality Analytics\nQA-13 – AI Product / Software QA","tools":"Cursor, Claude","reusableAssets":"Prompt/playbook patterns for QA use cases; review checklist","typicalEffort":"TBD","typicalDuration":"Ongoing","deliveryModel":"Internal enablement + delivery use","pricingUnit":"TBD","contribution":"Higher QA throughput without dropping accountability","maturity":"2 - Repeatable","gapsAndRisks":"Strategy: controlled adoption via pilots + human review","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-12","name":"Quality Analytics","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Make quality, cost and risk visible to management.","description":"Builds and maintains the dashboard and trends that turn QA activity into management signals: escaped defects, cycle time, gate compliance, technical-debt indicators and capacity pressure.","inScope":"KPI definitions; dashboards/trends; reporting cadence; insight for staffing and investment","outOfScope":"Owning company-wide BI platforms; commercial pricing decisions","trigger":"Monthly/quarterly management review, or when a quality gate framework needs measurable evidence","inputs":"Defect/test data; agreed KPI set; tooling access","keyActivities":["Define/confirm measures.","Collect signals from delivery.","Publish dashboard/trends.","Highlight risks and capacity.","Feed roadmap and staffing discussions."],"outputs":"Dashboard and trends","definitionOfDone":"Management can see current quality/risk posture without asking for an ad hoc spreadsheet","consumes":"QA-03 – Functional Validation\nQA-06 – Data Validation\nQA-08 – Release Readiness\nQA-09 – Production Validation\nQA-11 – AI-Assisted QA\nQA-13 – AI Product / Software QA","feeds":"DEL-03 – Run delivery assurance","tools":"Jira Dashboards, Confluence,Azure Application Insights / Grafana,SonarQube,Playwright reports, CI/CD reports","reusableAssets":"KPI dictionary; dashboard views","typicalEffort":"TBD","typicalDuration":"Continuous","deliveryModel":"Internal","pricingUnit":"Not applicable","contribution":"Evidence for QA investment versus defect/rework cost","maturity":"2 - Repeatable","gapsAndRisks":"Strategy: technical debt and downstream cost not yet a consistent QA value metric","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"},{"id":"QA-13","name":"AI Product / Software QA","owner":[{"name":"Vidhi Vinchhi","email":null}],"purpose":"Ensure AI-powered products are functionally reliable, accurate, safe, explainable and fit for business use.","description":"Validates AI-powered features and products against business use: functional reliability, accuracy/relevance, groundedness, safety/guardrails, regression across model/version changes, and risks such as hallucination, inconsistent responses, data leakage and prompt manipulation.","inScope":"AI evaluation scenarios; hallucination/groundedness checks; safety/guardrail tests; AI regression; critical AI defect reporting","outOfScope":"Training/fine-tuning models as a research function; legal sign-off on AI policy","trigger":"An AI-powered feature or product enters build/test, or a model/version change is planned","inputs":"Expected behaviours; evaluation sets; guardrail definitions; environment with model access","keyActivities":["Define AI evaluation criteria for the use case.","Build evaluation/regression sets.","Run accuracy, safety and regression checks.","Log critical AI defects.","Report pass rates and residual risk for release."],"outputs":"AI evaluation results; safety/guardrail evidence; AI regression results","definitionOfDone":"In-scope AI behaviours have evaluation evidence before release","consumes":"DEV-01 – Build product features\nQA-01 – Requirement Quality Review\nQA-02 – Risk & Test Planning\nQA-11 – AI-Assisted QA","feeds":"QA-08 – Release Readiness\nQA-12 – Quality Analytics","tools":"DeepEval, Ragas, promptfoo","reusableAssets":"AI evaluation packs; guardrail checklists","typicalEffort":"TBD","typicalDuration":"Per AI feature / model change","deliveryModel":"Billable + Internal","pricingUnit":"TBD","contribution":"Reduces hallucination, leakage and unsafe-response risk on AI offerings","maturity":"2 - Repeatable","gapsAndRisks":"Strategy capability for AI testing still to baseline; strong target state","status":"Draft – Strategy-aligned","versionDate":"v0.2 – 26 August 2026"}]}],"platforms":[{"id":"llm-dashboard","name":"LLM Dashboard","description":"Centralized dashboard for managing and monitoring LLM usage, AI gateways, configurations, and insights across environments.","owner":[],"status":"Live","links":{"pageUrl":"https://litellm.thetwym.com/ui/","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymx","name":"TwymX","description":"Core TwymX platform providing integrated capabilities for orchestration, AI-driven workflows, and enterprise solutions.","owner":[],"status":"Live","links":{"pageUrl":"https://uat.dev.twymx.com/","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymcall","name":"TwymCall","description":"Communication-focused platform enabling call workflows, integrations, and automation.","owner":[],"status":"Live","links":{"pageUrl":"https://twymcall.dev.twymx.com/","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymlaw","name":"TwymLaw","description":"Legal-focused solution designed to support legal workflows, documentation, and AI-assisted legal processes.","owner":[],"status":"Live","links":{"pageUrl":"https://twymlaw.dev.twymx.com/","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymspark","name":"TwymSpark","description":"AI-powered experimentation and innovation platform for rapid prototyping and intelligent use cases.","owner":[],"status":"Live","links":{"pageUrl":"https://twymspark.dev.twymx.com/","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymmind","name":"TwymMind","description":"Knowledge and intelligence platform for managing AI reasoning, insights, and cognitive workflows.","owner":[],"status":"Live","links":{"pageUrl":"https://twymmind.dev.twymx.com/","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymhub","name":"TwymPortal","description":"External-facing hub providing access to TwymX services, resources, and integrations.","owner":[],"status":"Live","links":{"pageUrl":"https://twymhub.thetwym.com/","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymops","name":"TwymWork","description":"Operations platform for managing infrastructure, deployments, and DevOps workflows across TwymX environments.","owner":[],"status":"Live","links":{"pageUrl":"https://twymwork.thetwym.com/","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymsense","name":"TwymSense","description":"Intelligent sensing and analytics platform for real-time data processing, monitoring, and AI-driven insights.","owner":[],"status":"Live","links":{"pageUrl":"https://dev.twymsense.thetwym.com/api-docs","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymguard","name":"TwymEdge","description":"PII detection and data privacy protection platform ensuring compliance and security across TwymX services.","owner":[],"status":"Live","links":{"pageUrl":"https://portal.dev.twymedge.thetwym.com","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twyminsight","name":"TwymInsight","description":"Web application for exploring, monitoring, and interacting with AI agent workflows inside the Twym product ecosystem. Gives operators and builders a single place to view agents, trace executions, try agents in a playground, and inspect BPMN-oriented workflows.","owner":[],"status":"Live","links":{"pageUrl":"https://dev.twyminsight.thetwym.com/","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}}],"products":[{"id":"mytwym","name":"MyTwym","description":"","owner":[],"status":"","links":{"pageUrl":"https://service-catalogue.dev.twymx.com/product.html?slug=mytwym","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymdesktop","name":"TwymDesktop","description":"","owner":[],"status":"","links":{"pageUrl":"https://service-catalogue.dev.twymx.com/product.html?slug=twymdesktop","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymreveal","name":"TwymReveal","description":"","owner":[],"status":"","links":{"pageUrl":"https://service-catalogue.dev.twymx.com/product.html?slug=twymreveal","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymwork","name":"TwymWork","description":"","owner":[],"status":"","links":{"pageUrl":"https://service-catalogue.dev.twymx.com/product.html?slug=twymwork","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}},{"id":"twymx","name":"TwymX","description":"","owner":[],"status":"","links":{"pageUrl":"https://service-catalogue.dev.twymx.com/product.html?slug=twymx","architectureUrl":null,"jiraUrl":null,"roadmapUrl":null}}]}