Our process, contract and exit terms — in writing
The whole of our digital agency working model is written on this page: what happens in each of the six phases, what is delivered, at which threshold it is accepted and who is accountable. Contract scope, service levels, reporting rhythm, copyright and ownership, technology handover and exit terms are on the same page. Corporate procurement finds the answers here rather than in a meeting.
What should a digital agency working model cover?
A working model has three layers: process (what is produced at each phase), acceptance (the threshold a deliverable must clear before it goes live) and contract (copyright, service levels, reporting, handover and exit). If all three are not written down, accountability becomes a mid-project argument. This page defines all three, item by item.
A corporate buyer choosing a supplier is looking for three answers: when do I get what, how do I know what I got is right, and what happens if something breaks or we part ways. These three questions usually surface at the contract table rather than in the proposal file — yet knowing the answers before the proposal both shortens procurement and makes comparison fair.
That is why we publish the model on an open page instead of a sales deck. The same text is an annexe to the contract; there is no difference between what you read here and what you sign. The six phases below are the corporate-scale rewrite of the six-step flow that has always described how we work: the same sequence, now with a written deliverable, a numeric acceptance threshold and a named accountable party at every step.
To see how the model is adapted per discipline, the scope matrix for our eleven services lists the deliverable and measurement criterion of each one separately. To see what the model produces, this site's own measured scores are published live, each with its measurement date.
What is done, delivered and measured in each of the six phases?
There are six phases: analysis, strategy, content planning, production, optimisation and reporting. Each phase has a written deliverable, a numeric measurement criterion, a named accountable party and a typical duration. The next phase does not start until the criterion is met; if it is missed, the correction is ours and is not billed as an extra item.
-
Analysis
Domains, sites, applications, business and social profiles, measurement setups and data flows are collected into a single table, with the owner and the access rights written next to each asset. In parallel the technical audit runs: crawl access, indexation status, Core Web Vitals, structured data and accessibility. Competitor scanning is done by measurement, not assertion — every finding is recorded with the page address, the tool and the date. This phase produces the data a decision needs, not the decision.
-
Strategy
The target buyer, the decision-maker role and the business goal are translated into measurable statements. Instead of “more traffic”, we write down which question set, which page type and which tool will be used to track progress. The information architecture draft, the language structure and the technology decision (static, headless or WordPress) are delivered with their reasoning. Out-of-scope items go into the same document, which is where the later “wasn't that included?” conversation is prevented.
-
Content planning
The question inventory is drawn from three sources: search data, the questions the sales team receives most often, and support records. Each page is given one primary question, an answer-first opening paragraph, a heading hierarchy, internal link targets and the sources it will cite. Defining every technical term where it first appears is part of the brief. A number without a source and a date does not enter a brief; and what does not enter a brief does not go live.
-
Production
Colour, typography and spacing decisions are written into a token file; pages are built with semantic HTML; the JSON-LD graph, hreflang mapping, forms and the consent flow are built in the same release. The visibility layer is part of production, not a plugin added afterwards. Performance budget and validation checks run before every merge, so regressions are caught before they reach production. A staging environment is open to you from the first week.
-
Optimisation
Before and after launch, lab and field data are measured separately. Root cause analysis is carried out for LCP — the time at which the largest visible element finishes rendering — as well as INP and CLS; accessibility is checked with an automated scan and with a keyboard and screen reader pass; answer-first passages, FAQ and HowTo schemas and the AI crawler policy are applied. Every fix is recorded with a before-and-after measurement, so “we improved it” never stands alone in a report.
-
Reporting
The monthly report is shared within the first five working days of each month and states plainly which metric was measured with which tool on which date. Measurement and interpretation sit in separate sections: the numbers first, then what we conclude from them, and the next month's priority list last. Priorities are re-ordered in a quarterly governance meeting. Measurement history is archived rather than deleted — a value that has fallen stays in the report.
The phases do not wait for one another; content planning, production and optimisation partly overlap. A typical total duration is 8–14 weeks. If only visibility work is commissioned (SEO, AEO, GEO or performance), the production phase narrows and the process drops to 4–6 weeks. How the model is adapted to individual disciplines is written on the corporate website and digital transformation consulting pages.
At what threshold does a deliverable go live?
Going live depends on a threshold, not an opinion. Twelve acceptance criteria are measured before launch is accepted: performance, Core Web Vitals, accessibility, structured data, title uniqueness, multilingual mapping, redirect integrity, content structure, crawler policy and source handover. Every row names its measurement tool and its measurement date.
| # | Criterion | Acceptance threshold | Measurement tool | When |
|---|---|---|---|---|
| 01 | Lighthouse Performance (mobile) | ≥ 95 | Lighthouse, mobile emulation | Before launch + day 30 |
| 02 | Largest Contentful Paint (LCP) | < 1.8 s | Lighthouse lab measurement | Before launch + day 30 |
| 03 | Cumulative Layout Shift (CLS) | < 0.05 | Lighthouse + field data | Before launch + monthly |
| 04 | Interaction to Next Paint (INP) | < 200 ms | Field data + interaction test | Monthly |
| 05 | Accessibility | WCAG 2.1 AA | Automated scan + keyboard and screen reader pass | Before launch |
| 06 | Structured data (JSON-LD) | 0 validation errors | Schema.org validator + rich result test | Before launch + every content release |
| 07 | Titles and descriptions | Unique on every address | Site-wide crawl report | Before launch + monthly |
| 08 | Language mapping (hreflang) | Reciprocal, x-default included | Site-wide crawl report | Before launch |
| 09 | Redirect integrity | Indexed addresses without a counterpart: 0 | Redirect table + crawl | Launch day |
| 10 | Content structure (answerability) | A single h1 and a self-contained answer block per page | Structure checklist + manual review | At content acceptance |
| 11 | AI crawler policy | robots.txt decision applied, llms.txt published | Live file check | Launch day |
| 12 | Source code and copyright transfer | Repository access, licence list, handover letter | Handover checklist | At launch, on final payment |
If one of the criteria is not met, launch is postponed and the correction belongs to us; it is not billed as an extra item. The reasoning behind the thresholds and the measurement method are set out in the Core Web Vitals guide, and the current results of these same criteria on our own site are published, with dates, on the proof page.
4.5:1
The minimum contrast ratio WCAG 2.1 requires for normal-size text. Under the fifth acceptance criterion, every text and background pair in the design system is verified against this threshold one by one.
Source: W3C — WCAG 2.1, Success Criterion 1.4.3 · Accessed: 2026-07-29 · open source (opens in a new tab) ↗
What is written into the contract?
Eight headings are written into the contract: scope and deliverable list, service levels (SLA), reporting rhythm, source code and design copyright, technology handover, exit terms, data protection responsibilities, and subcontracting with confidentiality. All eight are answered below, so no clause appears for the first time at signature.
1. What does the scope and deliverable list contain?
The first annexe to the contract is the deliverable list: the name, format, moment of delivery and acceptance criterion of every item sits on its own line. The same annexe also names what is out of scope — copywriting and photography are separate items, hosting and domain fees stay with the client, and third-party software licences are bought in the client's name.
Change management is defined here too: small corrections inside a phase are free, while requests that enlarge the scope are priced through a written addendum. That way the “we assumed this was included” discussion is resolved before signature rather than mid-project.
2. Service levels (SLA): what are your response and intervention times?
There are four priority levels, each with its own first-response time and intervention start. Durations are counted in working days and exclude public holidays; the applicable hours are defined in the contract annexe.
| Priority | Example situation | First response | Intervention |
|---|---|---|---|
| Critical | Site unreachable, form or order flow stopped, risk of data loss | Same working day | Same working day |
| High | An important page or function is broken; a technical fault affecting search visibility | 1 working day | 2 working days |
| Normal | Content update, minor copy or image error | 2 working days | In a planned release |
| Low | Improvement suggestion, request for a new section or feature | 5 working days | Planned on the roadmap |
The uptime commitment belongs to the hosting provider; the provider's own service level document is attached to the contract. Projects delivered as static output have a small server-side failure surface, but that on its own is not an uptime guarantee and is not presented as one.
3. In what rhythm do you report, and what does the report contain?
Reporting is monthly and shared within the first five working days of each month. The contents are fixed: a measurement table (metric, value, measurement tool, measurement date), the difference against the previous month, work completed, issues detected and next month's priority list. A 60-minute governance meeting is held quarterly; the meeting note and the updated priority list are shared in writing the same week.
You own the raw data sources behind the reports: the search console, analytics and server logs sit in your account, and our access is granted as an authorised user. That means you can verify the report independently.
4. Who owns the copyright of the source code and the design?
The client does. Source code, design files, content and imagery produced for the project are transferred at the end of the project; repository access is opened and a handover letter is signed. Licences for the open source components and fonts used — for example typefaces distributed under the SIL Open Font License — are listed individually in the handover file.
Third-party licensed assets — stock imagery, commercial plugins, payment provider modules — are bought in the client's name and stay in the client's name. Showing the work as a reference depends solely on your written consent; without it, we do not even disclose that the project exists.
5. How is technology handover carried out?
Handover has three parts. First, the repository and its version history: code is delivered with its history, not as a single compressed file. Second, run documentation: installation, build and deployment steps and environment variables are written down, so another team can take the project over. Third, account ownership: domain, DNS, hosting, search console, analytics and store accounts are opened in the client's name from the outset.
That third point is a deliberate choice: opening accounts in our own name would make the client dependent on us. Our access is always at authorised-user level, and ownership is never ours at any stage.
6. What is handed over if we part ways, and in what period?
When the contract ends, the following is transferred within 10 working days: full access to the repository and its version history, run and deployment documentation, design source files, the measurement history archive, the open task list and a note on known technical debt. Within the same period all of our access is removed, and that removal is confirmed in writing.
No fee is charged for handover, and code, content or data is never withheld. Termination requires 30 days' written notice: completed deliverables are invoiced and the phase in progress is calculated pro rata. These clauses are read alongside the general framework in the terms of use.
7. How are data protection responsibilities shared?
For site visitors' personal data the client acts as data controller and Baki Bilisim as data processor; the relationship is defined in a written data processing annexe. In Türkiye this is governed by KVKK (Personal Data Protection Law No. 6698), which is comparable to the GDPR in structure without being equivalent to it; for organisations subject to both, each regime is addressed separately. Form data goes directly to the client's server or corporate mailbox, and we keep no copy.
Analytics and tracking run only after the visitor's explicit consent. The privacy notice, consent flow and cookie policy are part of the delivery; legal review belongs to the client's own counsel. Our own data processing principles are set out in the privacy policy and KVKK notice.
8. Do you use subcontractors, and how is confidentiality protected?
We use them for specific specialisms: translation and localisation, illustration or video production, and load and security testing. Their use is notified in advance; every subcontractor is bound by the same confidentiality obligation and can access only the data their work requires. Accountability stays with us in every case — your point of contact and the single accountable name do not change.
On request, the items where no subcontractor will be used are listed individually in the contract. Who is accountable and how the team works is stated plainly on the about page.
What do we commit to, and what do we not?
We commit to what we can measure and control: deliverables, acceptance thresholds, response times, reporting rhythm and handover. We do not commit to what we cannot control: search rankings, the output of AI assistants, third-party platform policy decisions and competitor investment. The same distinction is written into the contract.
We commit to
- A written deliverable and a numeric acceptance threshold at every phase
- Every measurement reported with its tool and its date
- SLA response and intervention times tied to priority level
- Source code, design and content copyright resting with the client
- Complete handover within 10 working days if we part ways
- Correcting a missed acceptance criterion at no extra charge
We do not commit to
- A ranking guarantee for a particular keyword
- Your brand name appearing in ChatGPT, Perplexity or AI Overviews output
- Policy decisions of third-party platforms (search engines, app stores, social networks)
- A specific traffic, enquiry or revenue figure
- A fixed outcome independent of what competitors invest
The reasoning is simple: none of these items is under our control, and none of them can be verified independently. Generative engines are not deterministic; the same question can produce two different answers on the same day. So instead of promises we give method and measurement: our own site's measured scores are published with their dates, and the same measurement discipline is applied to client projects. Why we offer measurement rather than borrowed credibility is set out in detail on why Baki Bilisim.
Writing an RFP? A corporate website technical specification template
The template lists, heading by heading, what belongs in the RFP for a corporate website project: scope, acceptance criteria and thresholds, technical requirements, deliverable list, SLA, intellectual property and handover, data protection, and bid evaluation criteria. It is editable, carries no brand name and works with any supplier.
The problem procurement and IT teams meet most often is that incoming proposals cannot be compared: every supplier writes a different scope and a different definition of “success”. The template solves this with shared thresholds — by asking suppliers to accept the twelve criteria in clause 4 line by line, it brings every proposal onto the same scale.
At the end of the template there are five verifying questions that can be put to any agency (for example, “What is your own site's mobile Lighthouse score, and on what date was it measured?”). You are welcome to put them to us as well; the answers are already published on the proof page.
What is inside the template · 13 sections
- Organisation and project record
- Project purpose, items in scope and items out of scope
- Audience and decision scenario table
- Twelve acceptance criteria, suggested thresholds and measurement tools
- Content and search visibility requirements (schema, sitemap, crawler policy)
- Technical requirements: hosting, repository, environments, security headers, backups
- Deliverable list, with format and delivery moment columns
- Process, division of work, approval cycle and change management
- Service level (SLA) table
- Intellectual property, handover and exit clauses
- Personal data, confidentiality and regulation checklist
- Bid evaluation criteria and five questions to ask the supplier
- Attachments checklist
Download the specification template
Markdown (.md) · 10 KB · version 1.0 · 29 July 2026. No registration, e-mail address or form required. It may be reproduced with attribution and is not conditional on working with us.
Eight questions most often asked about the working model
Corporate buyers most often ask about eight things before requesting a proposal: the length of the process, when the first deliverable arrives, who owns the source code and design, SLA response times, what reporting contains, what is handed over on exit, subcontractor use, and minimum contract term. All eight are answered below, in the same wording as the contract.
How many phases are there and how long do they take?
The process has six phases: analysis, strategy, content planning, production, optimisation and reporting. The phases partly overlap; a typical corporate web project goes live within 8–14 weeks.
Three variables set the duration: whether the content is ready, how fast the approval cycle runs on the client side, and the number of languages. If only visibility work is commissioned, the production phase narrows and the process drops to 4–6 weeks.
When do I receive the first deliverable?
The first deliverable reaches you within 10 working days of signature: a digital asset inventory and a dated technical audit report.
It is a measurement output rather than a design or a presentation; every finding carries the page address, the measurement tool and the measurement date. Leaving no digital asset with an unclear owner is the acceptance criterion of the analysis phase. A free, narrower example of the same measurement approach is the digital asset audit.
Who owns the source code and the design?
The source code, design files, content and produced imagery belong to you. Repository access is transferred at the end of the project and a handover letter is signed; no locked panel and no hosting agreement that depends on us is required.
Licences for the open source components and fonts used are listed individually in the handover file. Showing the work as a reference depends solely on your written consent.
What is your SLA response time?
There are four priority levels. In a critical situation (site unreachable, form flow stopped, risk of data loss) the first response and the intervention are both within the same working day. At high priority the first response is 1 working day and intervention 2 working days.
Normal requests are answered within 2 working days and fixed in a planned release; improvement requests enter the roadmap within 5 working days. Durations are counted in working days and exclude public holidays. The full priority table is above.
How often do you report and what does the report include?
Reporting is monthly and shared within the first five working days of each month. The contents are fixed: a measurement table (metric, value, tool, measurement date), the difference against the previous month, work completed, issues detected and next month's priority list.
A 60-minute governance meeting is held quarterly. You own the raw data sources, which means you can verify the report independently.
What is handed over if we part ways?
When the contract ends, the following is handed over within 10 working days: the repository and its version history, run and deployment documentation, design source files, the measurement history archive, the open task list and a note on known technical debt.
Our own access is removed within the same period. No fee is charged for handover, and code, content or data is never withheld. Domain, hosting and measurement accounts are opened in your name from the start, so there is no ownership left to transfer.
Do you use subcontractors?
We use them for specific specialisms: translation and localisation, illustration or video production, and load and security testing. Their use is notified in advance; every subcontractor is bound by the same confidentiality obligation and can access only the data their work requires.
Accountability stays with us in every case and your point of contact does not change. On request, the items where no subcontractor will be used are listed individually in the contract.
Is there a minimum contract term?
In project work, scope rather than duration governs: the contract ends when the deliverable list is complete. For continuous visibility and maintenance work we suggest a horizon of at least three months, because measurement only becomes meaningful over that period; it is not a mandatory commitment.
Termination requires 30 days' written notice: completed deliverables are invoiced and the phase in progress is calculated pro rata. The pricing framework and other questions are covered on the frequently asked questions page.
See the measured state of your website within five working days.
The audit is free and creates no obligation to work with us. The report itemises findings on AEO answerability, AI crawler access, lab-measured Core Web Vitals, structured data validity and accessibility (automated scan). It is a free, narrow-scope example of the analysis phase above, so you can try the working model before asking for a proposal.
We work with corporate-scale, multi-location or multilingual organisations. One-off small jobs fall outside our scope; in that case we point you to smaller studios.