← Back to Help Centre
Planning a project

How pricing and quotations work

Pricing is based on confirmed scope, delivery risk, dependencies, uncertainty, and the level of implementation or support required.

Last reviewed

Celes7a does not publish a universal price for integration and automation work because the delivery effort and operational risk depend on the specific workflow, systems, interfaces, and responsibilities involved. A quotation follows enough discovery to define a useful and reviewable scope.

Why discovery comes before a quotation

Two workflows that look similar at a high level can require very different work. One system may provide a documented API and test environment, while another may have restricted interfaces, incomplete data, or an approval process involving several parties.

Discovery clarifies the intended outcome, workflow boundary, available interfaces, data mapping, security approach, failure behavior, acceptance criteria, and delivery dependencies. This reduces the risk of presenting a precise number that is based on unsupported assumptions.

What influences pricing

  • The number and complexity of systems and interfaces
  • The workflow rules, transformations, and approval steps
  • Authentication, permissions, and security requirements
  • Transaction volume, timing, and performance expectations
  • Data quality, migration, duplicate prevention, and reconciliation needs
  • Testing environments and stakeholder review availability
  • Deployment, monitoring, documentation, and handover responsibilities
  • The amount of uncertainty or third-party dependency
  • Post-launch assistance or ongoing support included in scope

Estimate, diagnostic, and quotation

An initial estimate is a planning indication based on the information available at that time. It can help decide whether to continue, reduce the scope, or divide the work into phases. It is not a replacement for the applicable written quotation.

When material uncertainty remains, Celes7a may recommend a focused diagnostic. That step can examine interfaces, permissions, data, or architecture and produce a clearer implementation path before a larger commitment is made.

A quotation describes the commercial scope for a particular engagement. It should identify the intended outcome, included work, assumptions, exclusions, dependencies, delivery approach, acceptance basis, and applicable commercial terms.

Changes after agreement

New systems, additional workflows, changed acceptance expectations, unavailable customer dependencies, or materially different data can affect cost and schedule. Significant changes should be reviewed and agreed rather than silently absorbed into the original scope.

Where practical, work can be staged so that a smaller useful result is delivered and validated before a broader phase. Staging can reduce uncertainty, expose dependency problems earlier, and make the commercial decision easier to review.

Keeping the commercial boundary clear

The quotation should make responsibilities visible, including customer access, test data, review, vendor coordination, deployment approval, and production operation. It should also identify assumptions that could change the delivery approach. Questions about an item should be resolved before approval so that price, scope, acceptance, and handover describe the same outcome.

What public content does not promise

Help Centre information does not create a fixed price, guaranteed delivery date, universal service level, or commitment to support a particular system. The approved written quotation and any associated agreement define those terms for the engagement.

How to request an estimate

Provide the current and desired workflow, systems, approximate volumes, known constraints, acceptance expectations, and preferred timing. A budget range is optional but may help identify the smallest appropriate first phase.

See the information needed for an estimate

Understand delivery stages and timelines

Discuss a project

Planning a project

How to start a project

Start by describing the current workflow, desired outcome, systems involved, and the problem that needs to be solved.

Planning a project

Typical delivery stages and timelines

Delivery normally moves through discovery, design, implementation, verification, release, and handover, with timing shaped by project dependencies.

Still need help?

Message us and we will normally reply by the next business day, Monday–Friday (IST).

Message us