Turn your scope and cost assumptions into a reviewable proposal.

Build a document in four steps

Goal → Scope and readiness → Cost assumptions → Proposal review. Describe the industry, current systems and work to improve, then connect the selected product to deliverables and acceptance criteria. After changing inputs, recalculate the proposal so it reflects the new conditions.

Useful preparation

• One recurring workflow, its current process and representative inputs and outputs
• A data owner, usable samples, a test environment and required integrations
• The business user who will assess the result and the responsible approver
• Target reductions in processing time, errors or rework, or required quality criteria

What the result helps you review

Inspect the work summary, selected product scope, readiness gaps, staged plan, deliverables and acceptance criteria. Cost follows entered effort or function points and the displayed reference. Review role costs, overhead, technical fees, direct expenses, subtotal and VAT separately.

How to read the estimate

Example effort is not a confirmed assessment of your actual workload. Person-days are different from calendar duration; parallel work, approval waits and data preparation affect the schedule. Check the rate year and source, then review inclusions and exclusions such as licenses, AI usage, cloud, hardware and specialist review. A binding price and delivery schedule follow review of real requirements, responsibilities and contract conditions.

If the effort has not been estimated yet

Use “AI scope and effort draft” to organize reviewable deliverables, acceptance criteria, role-based person-days, assumptions and open questions from the workflow description and selected product. Read the basis and unresolved conditions before explicitly applying the draft. You must still review the cost assumptions before the existing server formulas calculate an estimate.

AI-drafted effort is provisional. It does not determine rates, tax percentages or a contractual price. If effort or function points have already been assessed, use the direct-entry method to review them.

Compare implementation scope and cost structure

These are the 3 primary engagement tiers defined during technical consultation. Deliverables and acceptance criteria for each product can be reviewed immediately in your proposal.

• Bounded Pilot: Quickly validate feasibility, business impact, and integration behavior with one representative task and sample data.
  • Cost Structure: [One-time] Discovery, environment configuration, representative workflow validation / [Recurring] Actual infrastructure and AI token usage
  • Operating Responsibility: Customer (supplies sample data and evaluation criteria) / Giz (implements agreed scope and produces validation evidence)
  • Completion Criteria: Verified against predefined test scenarios; pilot findings report delivered with clearly stated support duration
• Workflow Implementation: Build production-grade screens, integrate legacy systems, migrate data, and complete operational handover.
  • Cost Structure: [One-time] Architecture design, development, migration, acceptance testing, handover / [Recurring] Software licenses, infrastructure, ongoing maintenance
  • Operating Responsibility: Customer (owns business policies, permissions, and change approvals) / Giz (builds and hands over contracted engineering assets)
  • Completion Criteria: Milestone acceptance, distinction between defect remediation and scope change, SLA and support boundary agreement
• Operations and Evolution: Long-term production observability, incident response, and continuous capability enhancement.
  • Cost Structure: [One-time] Transition setup and observability configuration / [Recurring] Agreed operations fee and consumption-based costs
  • Operating Responsibility: Customer (business priorities, access authorizations, organizational decisions) / Giz (maintains operational fabric)
  • Completion Criteria: SLA-backed incident response matrix, automated recovery runbooks, and periodic operational audits

Third-party foundation models, specialized APIs, and cloud infrastructure consumption are transparently itemized at direct cost.

Who prepares what and owns each decision?

Five fundamental boundary lines for reliable enterprise implementation and governance:

• 01. Goals and Baseline:
  • Customer Responsibility: Designate business workflow owner, specify core bottlenecks and measurable success criteria
  • Giz Delivery Scope: Structure workflow, input/output data contracts, and exception-handling architecture
  • Joint Review: Initial engagement boundary and definitive completion criteria
• 02. Data and System Access:
  • Customer Responsibility: Supply authorized test datasets, system accounts, and security guidelines
  • Giz Delivery Scope: Map source data schemas and enforce least-privilege connection boundaries
  • Joint Review: Schema reconciliation against live data and access boundary audit
• 03. Implementation and Engineering:
  • Customer Responsibility: Answer domain questions promptly and prioritize workflow change requests
  • Giz Delivery Scope: Implement agreed Occam4 living models, user interfaces, connectors, and agent automations
  • Joint Review: Working application completed end-to-end by actual business operators
• 04. Quality and Acceptance:
  • Customer Responsibility: Verify business calculation accuracy and operational usability
  • Giz Delivery Scope: Deliver full test evidence across normal operations, error states, permission checks, and recovery paths
  • Joint Review: Documented sign-off verifying 100% adherence to agreed acceptance criteria
• 05. Operations and Handover:
  • Customer Responsibility: Appoint system administrators, define operational shift coverage, and establish change approvers
  • Giz Delivery Scope: Deliver system configuration manuals, operator guides, and disaster recovery runbooks
  • Joint Review: Emergency contact network, automated backup/restore verification, and change control governance

Specific deliverables, responsibilities and support terms are finalized through project review and contract. Identify who supplies test data and business decisions before assessing schedule assumptions.

A change in scope requires a change in the proposal

For additional screens, integrations, migrations or output formats, record the original scope, requested change, added effort, acceptance criteria and schedule impact together. Keep unknown data or external-system conditions visible as prerequisites. An unresolved dependency is not a completed deliverable.

What consultation and the proposal tool provide

The consultation agent organizes implementation options using the question and public material. The AI scope and effort draft proposes deliverables, person-days, assumptions and unresolved questions for review. The proposal tool uses the applied draft or the selected product's standard scope with the final inputs. Examining an original RFP, customer data and integration conditions to confirm scope and effort, negotiating price and entering a contract remain separate review activities.

Demonstrate completion within a bounded scope

The tool's 14-day sequence illustrates a scoped pilot. It requires a defined task, samples, an owner and an environment; it is not a delivery promise for every project. Acceptance means a real user can finish the work and verify sources, results, permissions, errors and recovery.

Save the result for internal review or send the completed scope with a consultation request. You can also clarify the workflow with an agent first.