An applicable blank field is incomplete. If a field genuinely does not apply, record the reason, boundary and confirming owner; do not use Not applicable for missing evidence or uncertain applicability.

# Saudi Shared Services Starting Workbook

Article 1 in the Shared Services series

Use this workbook to assess one defined service, organize the evidence, and prepare a recommendation for an accountable decision forum. The workbook supports a decision. It does not make the decision.

It also does not replace accountable Saudi legal, regulatory, cybersecurity, data, tax, procurement, workforce, finance, or sector review. Refer each specialist question to a qualified owner before anyone changes live work.

Shared Services can organize a defined service, or a related service family, for several service customers through a common arrangement. A service customer is any intended recipient of the service. An internal customer sits inside the organizational boundary being assessed. A government entity served by a government program may be described as a beneficiary or recipient. Delivery may be internal, external, or mixed. Sourcing is a separate decision from service ownership, authority, and controls.

The [companion English article](https://alkulaib.io/blog/what-shared-services-means-in-a-saudi-organization) explains the reasoning behind this workbook. 

## 1. How to use this workbook

Work through one service at a time. Do not begin by deciding that an entire department should move.

1. Ask the sponsor to confirm the assignment, the decision owner, and the decision forum.
2. Define the assessed boundary and one service before requesting evidence.
3. Route questions to the people who own the facts or authority. A full-room workshop is rarely necessary.
4. Record what the evidence shows, its period, and its limitations. Do not turn an interview or guess into a confirmed fact.
5. Trace ordinary work and meaningful exceptions using actual records and cases.
6. Sketch at least two preliminary arrangements, including a current-state remedy where credible. Give each an option ID and boundary version, then test the same proposed boundary through all seven lenses. Never add the answers into a total score.
7. Compare authority and organizational alternatives.
8. Prepare the decision brief. The decision owner may approve, reject, narrow, return, or defer it.

Use Not known when evidence cannot support an answer. Every unknown needs an owner, due date, explicit consequence for the recommendation or affected action, and escalation route. Record ordinary evidence gaps in evidence follow-up. Use local validation only for a question that may involve a binding requirement or authority. Hold the affected implementation until the qualified owner resolves that question; risk acceptance cannot establish whether a requirement applies or authority exists. An operational gap may require more evidence, a narrower proposal or deferral. If it prevents you from establishing readiness for the proposed pilot, hold that pilot too.

### Start in the ledger, finish with a decision

Use the [bilingual Services Ledger](https://media.alkulaib.io/11a6815b-c41f-465e-8ef2-b142836fc729.xlsx) to list candidate services. Choose one language for live entries; the parallel sheets are not two registers to maintain. Keep the same service ID in this workbook, evidence records, options, capacity sheet and decision brief. Link the ledger's detailed-assessment reference to this completed workbook.

| Record header | Your entry |
|---|---|
| Service ID / service result |  |
| Units, assessed boundary and version |  |
| Assessment owner / review date |  |
| Ledger row / completed-workbook location |  |
| Option IDs / decision-brief reference |  |

The three decisions are the sequence: define the service, settle its authority boundary, then choose the structure. The lenses examine evidence for preliminary alternatives; they do not invent the alternative being assessed. Revise the boundary and affected lens answers together. The timetable organizes the work; the decision brief records its outputs. These 15 sections are working resources, not 15 separate approvals.

Active ledger rows need a next action, owner and valid Excel due date. Deferred work needs a dated reconsideration action. An excluded row without a blocker needs no active follow-up. The formula checks intake fields, not evidence quality or authorization to implement.

### Evidence rules

Acceptable evidence identifies its source, owner, and period. Examples include an approved mandate, policy, delegation, case record, system report, control test, cost ledger, contract, organization record, or a confirmed case trace. A redacted sample may be enough when the underlying record contains personal, confidential, commercially sensitive, or security-sensitive information.

Use these confirmation labels consistently:

- **Confirmed:** supported by a named record and confirmed by the accountable owner.
- **Observed:** seen in a named record or traced case but awaiting owner confirmation.
- **Reported:** stated in an interview and not yet corroborated.
- **Calculated:** derived from named inputs using a recorded method.
- **Assumed:** used temporarily for analysis and still requires validation.
- **Disputed:** relevant owners disagree about the fact or its meaning.
- **Not known:** evidence is missing, inaccessible, outside authority, or too weak to answer.

Stop and escalate if evidence access exceeds the analyst's authority, the records conflict on a decision that matters, a specialist conclusion is required, or anyone asks the analyst to present an assumption as fact.

## 2. Plain-language terms

Read these definitions before completing the assignment pages.

| Term | Meaning in this workbook |
|---|---|
| Sponsor | The accountable leader who requested the assessment, confirms its purpose, and removes major barriers. |
| Decision owner | The person or forum with authority to approve, reject, narrow, pause, or stop the proposed action. The sponsor and decision owner may be different. |
| Boundary | The legal entities, units, locations, people, systems, services, decisions, and time period included in the assessment, plus what is excluded. |
| Service | A defined result delivered after an agreed trigger or valid request. Use a result such as issuing an employment letter, not a function name such as Human Resources. |
| Baseline | The documented current starting point for a stated service, population, and period. It allows options or a pilot to be compared on the same basis. |
| Handoff | The point where work, information, or responsibility passes to another person, team, or system. |
| Exception | A case that cannot follow the ordinary path because its information, authority, risk, or circumstances differ. |
| Retained decision | A decision that remains with a named subsidiary, business unit, profession, policy owner, control owner, or executive while related work may be shared. |
| Bounded pilot | A temporary test with a named service, service customers, authority, duration, measures, owner, stop conditions, and safe rollback route. |
| System of record | The named place where the organization treats the final approved record as authoritative. Write the actual system, register, or controlled file name. |

## 3. Assignment and authority

### How to complete this page

**Write:** Record the exact decision, boundary, service, authority, deadline, forum, specialist questions, and stop conditions.  
**Ask:** Sponsor first; decision owner if that is a different person.  
**Acceptable evidence:** Written assignment, mandate, delegation, forum terms of reference, approved organization records, and a dated message confirming scope.  
**Produce:** A one-page assignment note approved for assessment work.  
**Stop or escalate:** Do not start evidence collection until the decision owner, boundary, and analyst authority are clear.

### Assignment record

| Field | What to record | Your response |
|---|---|---|
| Sponsor | Name, role, and contact route. |  |
| Decision owner | Person or forum authorized to make the requested decision. |  |
| Decision requested | One sentence naming the exact decision this assessment must support. |  |
| Why this decision is needed | Service problem, opportunity, or evidence gap without assuming the answer. |  |
| Organization type | Select one: ☐ private company ☐ group ☐ government entity ☐ government-owned entity ☐ nonprofit ☐ other. Describe other in plain words. |  |
| Assessed organizational boundary | Legal entities, business units, subsidiaries, government entities, locations, and period included. |  |
| Excluded boundary | Excluded entities, locations, services, decisions, systems, periods, sourcing questions, and legal-form questions. |  |
| Service being assessed | One observable service result. |  |
| Service customers | Every intended recipient group. Identify internal customers and government beneficiaries or recipients. |  |
| Analyst | Name and role. |  |
| Authority granted to the analyst | Records that may be requested, interviews that may be conducted, and analyses that may be prepared. |  |
| Authority not granted | Decisions and actions outside the analyst's authority. |  |
| Deadline | Date and time zone. |  |
| Decision forum | Meeting, committee, executive, board, or other forum that will receive the brief. |  |
| Required reviewers | Only owners whose evidence or authority is material to this service. |  |
| Sponsor confirmation | Date, method, and evidence reference for confirmation. |  |

### Saudi specialist-review questions

Write each question narrowly enough for its accountable owner to answer. Do not ask the analyst to interpret an official requirement.

| Area | Question for this service | Accountable owner | Why it could affect the decision |
|---|---|---|---|
| Personal data across entities | What personal data crosses an entity boundary; who determines purpose and means; who processes for whom; and what lawful basis, disclosure condition, notice, access, retention, or agreement is required? |  | PDPL roles, disclosure, sharing, and controls may change the service boundary. |
| Cybersecurity across a shared platform | Which NCA, sector, Digital Government Authority, or contractual controls apply; and how will access, segregation, logging, incidents, continuity, and evidence be managed? |  | Applicability and control design may block or condition the platform and operating boundary. |
| VAT and intercompany charging | Are service charges subject to VAT; are the entities in one approved VAT group; and what invoicing, accounting, transfer-pricing, and audit evidence is required? |  | The entity and charging model can change comparable economics and implementation requirements. |
| Employee and social-insurance transfer | If people move to another employer, what Qiwa contract or service-transfer process, employee action, and GOSI registration change is required for each employee category? |  | Employer, contract, payroll, benefits, registration, and transition duties may change or block the form. |
| Saudization and Nitaqat | How would the proposed entity, commercial registration, activity, workforce mix, profession classification, and documented contracts affect the applicable Saudization position? |  | A new legal form or workforce boundary can change the organization's applicable position. |
| Government procurement | If a covered government entity is involved, how does the Government Tenders and Procurement Law affect competition, approvals, contracting, records, supplier action, and execution? |  | The applicable procurement regime can reserve decisions or constrain the service and contracting model. |
| Other law, regulation, or sector duty | Which license, delegation, professional responsibility, safety duty, regulator, or contractual obligation changes what may be shared or who may decide? |  |  |

### Immediate stop and escalation conditions

Agree these conditions with the sponsor before work begins.

| Stop condition | Person authorized to stop work | Escalation route | Evidence to retain |
|---|---|---|---|
| Record access would exceed granted authority or expose unnecessary protected information. |  |  |  |
| No one can demonstrate who owns the requested decision. |  |  |  |
| The assignment prescribes a result such as centralizing everything before assessment. |  |  |  |
| A live process, control, role, supplier, system, or customer commitment would change during assessment. |  |  |  |
| A material Saudi specialist question has no accountable reviewer. |  |  |  |
| Write any service-specific stop condition. |  |  |  |

## 4. Stakeholder route and interview tools

Choose interviewees from the service and question. Do not invite every listed role to every meeting. Ask each question of the accountable owner, record the evidence reference, and send a short factual summary for correction.

### Sponsor and current operation

| Person to ask | Specific questions | Evidence expected | Output and escalation |
|---|---|---|---|
| Sponsor | What exact decision is required? Why now? What outcome would cause you to stop, narrow, or defer the work? Which forum owns the decision? | Written assignment, mandate, forum record, boundary confirmation | Confirm the assignment note. Escalate a prescribed answer, conflicting sponsors, or no decision owner. |
| Current service owner | What result are you accountable for? Which decisions and obligations must remain with you? Which service customers and exceptions matter most? | Service description, policy, delegations, service reports, exception records, owner confirmation | Produce the owner and retained-decision record. Escalate disputed ownership or an authority gap. |
| Delivery staff | Show one recent ordinary case and one meaningful exception. Where did work wait, return, duplicate, bypass a control, or leave the formal procedure? | Redacted case records, timestamps, queue records, working instructions, system history | Correct the current-state map. Escalate unsafe workarounds, unrecorded decisions, or missing control evidence. |
| Service customers or internal customers | What result do you receive? What must you provide? Where do you lose time, visibility, or confidence? Which variation is necessary, and what record proves it? | Requests, completion notices, complaints, escalations, returned cases, customer obligations | Produce the service-customer map and confirmed service result. Escalate conflicting customer definitions or a promised result without an owner. |
| System owner | Which fields, timestamps, statuses, and access records are reliable? Where is the final authoritative record? What is manual or overwritten? | System configuration, data dictionary, access record, audit trail, report logic, recovery evidence | Produce the system and data-source note. Escalate an unreliable baseline, uncontrolled access, or no recoverable record. |

### Accountable specialist owners

| Person to ask | Specific questions | Evidence expected | Output and escalation |
|---|---|---|---|
| Finance | Which cost items belong to the current and proposed service boundary? Which retained, transition, governance, control, and reversal costs must remain visible? | General-ledger extract or approved cost report, allocation method, staffing-cost assumptions, supplier costs, finance confirmation | Produce comparable economics. Escalate omitted costs, inconsistent periods, unsupported savings, or a financing decision outside scope. |
| Human Resources | What capacity, skills, roles, reporting, localization, leave coverage, training, or employee effects arise? Which workforce decision remains retained? | Organization records, role descriptions, capacity data, workforce plans, approved HR policies, specialist confirmation | Produce the workforce and capacity note. Escalate proposed role or employment changes without authority and qualified review. |
| Legal | Which legal entity, delegation, contract, professional responsibility, record, dispute, or jurisdiction question affects the boundary? Who may give the required advice? | Current legal instruments, approved delegations, contract terms, counsel opinion or recorded legal confirmation | Produce a bounded legal-validation entry. Escalate any request for the analyst to interpret law or provide legal advice. |
| Procurement | Which procurement authority, method, platform, contract, supplier, local-content, or approval rule affects the service? Who decides the contractual response? | Procurement policy, delegations, contract and approval records, supplier-performance records, procurement confirmation | Produce the procurement authority map. Escalate supplier selection, contract change, notice, or remedy without an authorized owner. |
| Risk | What failure events, concentration effects, risk limits, dependencies, and acceptance routes apply to each option? | Risk register, incident history, control assessment, continuity tests, approved risk appetite or treatment record | Produce the risk comparison. Escalate an unowned material risk or proposed risk acceptance. |
| Compliance | Which obligations, monitoring duties, approvals, or reporting records apply to this service and organizational boundary? | Compliance inventory, monitoring results, findings, official requirements, compliance confirmation | Produce the compliance-validation entry. Escalate unclear applicability that could block implementation. |
| Data | What information is used, for what purpose, under which data roles, and with what quality, location, retention, and sharing conditions? | Data inventory, classification, data-flow map, retention schedule, quality report, owner confirmation | Produce the data-boundary note. Escalate unclear authority, unnecessary data, uncontrolled movement, or material quality failure. |
| Cybersecurity | Which access, identity, logging, integration, resilience, supplier, or sector controls apply? Who accepts residual cyber risk? | Architecture and data-flow records, access reviews, control tests, incident history, recovery results, cybersecurity confirmation | Produce the cyber-control note. Escalate unsupported access, missing logging, untested recovery, or unaccepted risk. |
| Sector specialist | Which licensed duty, safety requirement, professional judgment, reporting obligation, or regulator-specific limit affects the service? | Named Saudi authority, license, official rule, approved procedure, specialist confirmation | Produce a sector-validation entry. Stop if a licensed or safety-critical decision lacks a qualified owner. |

### Interview confirmation record

Use the same Interview ID in both parts.

#### Interview record, part A

| Interview ID | Interviewee | Date | Cases or records discussed |
|---|---|---|---|
| INT-01 |  |  |  |
| INT-02 |  |  |  |

#### Interview record, part B

| Interview ID | Summary sent | Correction received | Confirmation status | Evidence reference |
|---|---|---|---|---|
| INT-01 | ☐ | ☐ |  |  |
| INT-02 | ☐ | ☐ |  |  |

## 5. Evidence and local-validation registers

### How to complete this page

**Write:** One row for each fact that affects the recommendation and one row for each unresolved specialist question.  
**Ask:** The source owner confirms the fact; the accountable owner resolves applicability.  
**Acceptable evidence:** Named records for a stated period, redacted case samples, reproducible calculations, and written owner confirmation.  
**Produce:** Evidence register plus local-validation register.  
**Stop or escalate:** Stop when a material claim relies only on memory, when the same field has conflicting definitions, or when a blocking question has no owner and date.

### Evidence register

Use the same Evidence ID in both parts.

#### Evidence description and source

| Evidence ID | Claim or question supported | Source | Period | Owner |
|---|---|---|---|---|
| EVD-01 |  |  |  |  |
| EVD-02 |  |  |  |  |
| EVD-03 |  |  |  |  |

#### Evidence quality and follow-up

| Evidence ID | Quality | Limitation | Confirmation status | Escalation |
|---|---|---|---|---|
| EVD-01 |  |  |  |  |
| EVD-02 |  |  |  |  |
| EVD-03 |  |  |  |  |

For quality, record the basis in plain words, such as complete system extract, redacted sample, traced case, approved document, interview only, inconsistent definition, or unavailable record.

### Evidence follow-up: operational questions

Keep the service ID with each EVD evidence reference and GAP question. A Not known lens answer links here unless it is potentially binding, in which case use VAL. If both issues exist, create distinct linked entries.

| Gap ID / evidence reference | Missing fact / what it prevents you establishing | Owner / due date | Next action / consequence for proposal or pilot | Escalation / closure evidence |
|---|---|---|---|---|
| GAP-01 / EVD- |  |  |  |  |
| GAP-02 / EVD- |  |  |  |  |

Name the affected action, not just “blocked”: for example, “do not start the two-unit pilot until peak coverage is demonstrated.” Closure cites the new evidence and the reviewer who confirmed what it establishes.

### Local-validation register

Use the same Validation ID in both parts. Reserve VAL for potentially binding applicability or authority questions. State the affected service, units, action and boundary version in the question; hold that action until resolution.

#### Validation question and ownership

| Validation ID | Question | Evidence needed | Accountable owner |
|---|---|---|---|
| VAL-01 |  |  |  |
| VAL-02 |  |  |  |
| VAL-03 |  |  |  |

#### Validation status and escalation

| Validation ID | Status | Due date | Blocking effect | Escalation route |
|---|---|---|---|---|
| VAL-01 |  |  |  |  |
| VAL-02 |  |  |  |  |
| VAL-03 |  |  |  |  |

Use one status: ☐ Open ☐ In review ☐ Confirmed ☐ Confirmed not applicable ☐ Disputed ☐ Not known. Closing an entry requires the qualified reviewer, dated source and conclusion. Confirmed not applicable needs an explicit reason tied to this boundary; it does not mean “we found nothing.” It is a validation status, not a fifth lens answer. If applicability is still uncertain, retain Not known and the affected-action hold.

| Validation ID | Resolution / reason if not applicable | Qualified reviewer / date | Source / scope proved | Hold released or retained / remaining conditions |
|---|---|---|---|---|
| VAL-01 |  |  |  |  |

## 6. Define the service and its service customers

### How to complete this page

**Write:** Describe one result, its trigger, start and end points, service customers, inputs, exclusions, current owner, and retained decisions.  
**Ask:** Current service owner, delivery staff, representative service customers, and system owner.  
**Acceptable evidence:** Service description, policy, valid-request rules, system fields, completed and rejected cases, and owner confirmation.  
**Produce:** One-service definition and service-customer map.  
**Stop or escalate:** Stop if the scope contains unrelated outcomes, service customers disagree on the result, or a proposed boundary moves authority without an authorized owner.

### One-service definition

| Field | What to record | Your response |
|---|---|---|
| Service name | Observable result, not a department or team name. |  |
| Service purpose | Customer need the service meets. |  |
| Trigger | Event or valid request that starts work. |  |
| Start point | First included action. |  |
| End point | Accepted output and how completion is recorded. |  |
| Required inputs | Information, approvals, or conditions required before work starts. |  |
| Ordinary cases included | Cases expected to follow the ordinary path. |  |
| Exceptions included | Exceptions that remain inside the service boundary. |  |
| Explicit exclusions | Work, decisions, entities, locations, systems, and cases outside the boundary. |  |
| Current service owner | Role accountable for the current result. |  |
| Retained decisions | Each decision that stays outside the proposed shared boundary and its owner. |  |
| Authoritative record | System, register, or controlled file holding the final approved record. |  |

### Service-customer map

Use the same Customer ID in both parts.

#### Service-customer result

| Customer ID | Service-customer group | Recipient type | Result received |
|---|---|---|---|
| CUS-01 |  | ☐ Internal customer ☐ Government beneficiary or recipient ☐ Other |  |
| CUS-02 |  | ☐ Internal customer ☐ Government beneficiary or recipient ☐ Other |  |
| CUS-03 |  | ☐ Internal customer ☐ Government beneficiary or recipient ☐ Other |  |

#### Service-customer obligations and variation

| Customer ID | What the customer must provide | Necessary variation | Evidence and owner |
|---|---|---|---|
| CUS-01 |  |  |  |
| CUS-02 |  |  |  |
| CUS-03 |  |  |  |

## 7. Establish the current baseline

### How to complete this page

**Write:** Record the current measure, definition, period, source, owner, and limitation. Keep measured values separate from estimates.  
**Ask:** Service owner, delivery staff, system owner, Finance, Human Resources, and representative service customers as relevant.  
**Acceptable evidence:** System extracts, queue reports, time samples, staffing records, cost reports, complaints, control tests, and traced cases.  
**Produce:** A dated baseline for the exact service boundary.  
**Stop or escalate:** Stop if periods or definitions cannot be compared, regulated data cannot be accessed safely, retained cost is omitted, or an estimate is presented as measured.

### Baseline measures

Use the same Measure ID in both parts.

#### Baseline definition and value

| Measure ID | Measure | Plain definition | Period | Value or finding |
|---|---|---|---|---|
| BASE-01 | Request volume by type |  |  |  |
| BASE-02 | Demand pattern and peak period |  |  |  |
| BASE-03 | Handling time |  |  |  |
| BASE-04 | Waiting time |  |  |  |
| BASE-05 | Backlog and age |  |  |  |
| BASE-06 | Errors, returns, and rework |  |  |  |
| BASE-07 | Exception mix |  |  |  |
| BASE-08 | Service hours and coverage |  |  |  |
| BASE-09 | People effort and capacity |  |  |  |
| BASE-10 | Systems and supplier cost |  |  |  |
| BASE-11 | Control failures or open findings |  |  |  |
| BASE-12 | Service-customer effort or complaint evidence |  |  |  |

#### Baseline source and limitation

| Measure ID | Source | Owner | Limitation |
|---|---|---|---|
| BASE-01 |  |  |  |
| BASE-02 |  |  |  |
| BASE-03 |  |  |  |
| BASE-04 |  |  |  |
| BASE-05 |  |  |  |
| BASE-06 |  |  |  |
| BASE-07 |  |  |  |
| BASE-08 |  |  |  |
| BASE-09 |  |  |  |
| BASE-10 |  |  |  |
| BASE-11 |  |  |  |
| BASE-12 |  |  |  |

### Baseline confirmation

| Check | Result |
|---|---|
| Service boundary matches the one-service definition | ☐ Confirmed ☐ Mixed ☐ Not known |
| Period is stated and representative enough for the decision | ☐ Confirmed ☐ Mixed ☐ Not known |
| Definitions are consistent across sources | ☐ Confirmed ☐ Mixed ☐ Not known |
| Finance confirmed the cost scope | ☐ Confirmed ☐ Mixed ☐ Not applicable ☐ Not known |
| Source owners confirmed material data limits | ☐ Confirmed ☐ Mixed ☐ Not known |

## 8. Map current work, exceptions, and responsibility

### How to complete this page

**Write:** Trace at least one ordinary case and one meaningful exception. Record each handoff, decision, control, system, and retained record.  
**Ask:** Delivery staff, current owner, policy or process owner, system owner, service customer, and the owner of each material exception.  
**Acceptable evidence:** Redacted case history, timestamps, approvals, messages retained as official evidence, system audit history, procedures, control records, and participant confirmation.  
**Produce:** Current-state map and seven-stage responsibility map.  
**Stop or escalate:** Stop for conflicting authority, control bypass, unowned exception, missing official record, or a request to waive a rule or accept risk.

### Ordinary case trace

Use the same Trace ID across all three parts.

#### Ordinary trace action and role

| Trace ID | Step | Trigger or input | Action | Responsible role |
|---|---|---|---|---|
| ORD-01 | 1 |  |  |  |
| ORD-02 | 2 |  |  |  |
| ORD-03 | 3 |  |  |  |
| ORD-04 | 4 |  |  |  |

#### Ordinary trace authority and control

| Trace ID | Authoritative record or system | Decision authority or rule | Control | Handoff |
|---|---|---|---|---|
| ORD-01 |  |  |  |  |
| ORD-02 |  |  |  |  |
| ORD-03 |  |  |  |  |
| ORD-04 |  |  |  |  |

#### Ordinary trace retained evidence

| Trace ID | Output and retained evidence |
|---|---|
| ORD-01 |  |
| ORD-02 |  |
| ORD-03 |  |
| ORD-04 |  |

### Exception case trace

Use the same Trace ID across all three parts.

#### Exception trace action and role

| Trace ID | Step | What made the case different | Action | Responsible role |
|---|---|---|---|---|
| EXC-01 | 1 |  |  |  |
| EXC-02 | 2 |  |  |  |
| EXC-03 | 3 |  |  |  |
| EXC-04 | 4 |  |  |  |

#### Exception trace authority and control

| Trace ID | Authoritative record or system | Decision authority used | Control | Escalation or handoff |
|---|---|---|---|---|
| EXC-01 |  |  |  |  |
| EXC-02 |  |  |  |  |
| EXC-03 |  |  |  |  |
| EXC-04 |  |  |  |  |

#### Exception trace retained evidence

| Trace ID | Output and retained evidence |
|---|---|
| EXC-01 |  |
| EXC-02 |  |
| EXC-03 |  |
| EXC-04 |  |

### Ordinary-path seven-stage responsibility map

Use the stages in this exact order. Use the same Stage ID in both parts and record the ordinary path only.

#### Ordinary responsibility and authority

| Stage ID | Stage | Responsible role | Decision authority |
|---|---|---|---|
| ORD-DETECT | detect |  |  |
| ORD-DOCUMENT | document |  |  |
| ORD-ESCALATE | escalate |  |  |
| ORD-DECIDE | decide |  |  |
| ORD-EXECUTE | execute |  |  |
| ORD-COMMUNICATE | communicate |  |  |
| ORD-MONITOR | monitor |  |  |

#### Ordinary record, control, and evidence

| Stage ID | Authoritative record or system in plain language | Control | Handoff | Retained evidence |
|---|---|---|---|---|
| ORD-DETECT |  |  |  |  |
| ORD-DOCUMENT |  |  |  |  |
| ORD-ESCALATE |  |  |  |  |
| ORD-DECIDE |  |  |  |  |
| ORD-EXECUTE |  |  |  |  |
| ORD-COMMUNICATE |  |  |  |  |
| ORD-MONITOR |  |  |  |  |

### Exception-path seven-stage responsibility map

Use the same Stage ID in both parts. Record the exception path separately. Do not copy an ordinary-path role or authority unless evidence shows that it remains responsible for the exception.

#### Exception responsibility and authority

| Stage ID | Stage | Responsible role | Decision authority |
|---|---|---|---|
| EXC-DETECT | detect |  |  |
| EXC-DOCUMENT | document |  |  |
| EXC-ESCALATE | escalate |  |  |
| EXC-DECIDE | decide |  |  |
| EXC-EXECUTE | execute |  |  |
| EXC-COMMUNICATE | communicate |  |  |
| EXC-MONITOR | monitor |  |  |

#### Exception record, control, and evidence

| Stage ID | Authoritative record or system in plain language | Control | Handoff | Retained evidence |
|---|---|---|---|---|
| EXC-DETECT |  |  |  |  |
| EXC-DOCUMENT |  |  |  |  |
| EXC-ESCALATE |  |  |  |  |
| EXC-DECIDE |  |  |  |  |
| EXC-EXECUTE |  |  |  |  |
| EXC-COMMUNICATE |  |  |  |  |
| EXC-MONITOR |  |  |  |  |

## 9. Seven-Lens worksheets

The Seven-Lens method is an Alkulaib.io planning heuristic. It is not an externally validated benchmark, legal test, maturity model, or automatic recommendation. Law, regulation, delegated authority, security, duty of care, and control obligations may override it.

Complete each lens for the one service and boundary already defined. Every lens tests the same proposition: **within this lens, the evidence supports placing this defined service in the proposed shared arrangement under the stated conditions.** Use only `Yes / No / Mixed / Not known`.

| Response | Meaning for the proposed shared-delivery boundary |
|---|---|
| Yes | Evidence from this lens supports the proposed shared-delivery boundary. |
| No | Evidence from this lens opposes the proposed boundary or shows that it cannot satisfy this lens. |
| Mixed | Evidence supports only part of the service or boundary, differs across cases or service customers, or conflicts. |
| Not known | Evidence is insufficient. Link evidence follow-up or, for a potentially binding question, local validation. Record owner, due date, consequence and escalation; do not guess. |

There is no total Seven-Lens score. Apply these resolution rules:

1. Lenses 1 and 2 expose binding obligations, authority, and material risk. A binding obligation, missing authority, or unmitigated material risk can block or condition implementation. A No label alone is not an automatic veto.
2. Every Not known answer needs an owner, deadline, consequence and escalation. A potentially binding question goes to local validation and holds affected implementation until the qualified owner resolves it. Risk acceptance is not a substitute for resolution. An operational gap also holds the affected pilot if readiness cannot be established.
3. Lenses 4, 5, and 6 establish the operational and economic case through demand, coordination burden, and full comparable economics.
4. Lenses 3 and 7 shape the boundary, organizational form, and pace through strategic proximity, differentiation, capability, systems, sponsorship, and behavior.

The decision owner weighs evidence and limitations. A No comes with evidence that can be weighed; Not known identifies evidence still missing. Each lens record names the option ID and boundary version and links to evidence follow-up or local validation as appropriate. A fact can settle one question without settling the whole lens.

### 1. Regulatory and accountability necessity.

| Required item | Workbook instruction |
|---|---|
| Assessment question | Do the identified Saudi regulatory and accountability obligations create a need for common accountability, and can the proposed shared-delivery boundary lawfully and operationally carry that accountability while preserving retained duties? |
| Response interpretation | Yes means evidence supports both parts of the question. No means common accountability is not needed or the proposed boundary cannot carry it. Mixed means only some obligations, services, or customers satisfy both parts, or the evidence conflicts. Not known means evidence is insufficient; route the specific gap to evidence follow-up or local validation according to what remains unproved. |
| Action | Identify obligations, reserved authorities, accountable ownership, required approvals, and decisions that must remain explicit. |
| People to ask | Sponsor, decision owner, current owner, Legal, Compliance, policy owner, and sector specialist as applicable. |
| Evidence | Current official requirements, licenses, delegations, policies, governance records, audit findings, and qualified owner confirmation. |
| Output | A validated list of mandatory ownership, authority, approvals, retained decisions, and unresolved applicability questions. |
| Escalation trigger and route | Route any unclear binding obligation, disputed owner, or non-delegable authority to the decision owner and qualified specialist. Stop implementation until a blocking item closes. |

#### Lens 1 answer and evidence

| Lens record ID | Answer for proposed shared boundary | Evidence reference and finding | Evidence limitation | Accountable owner |
|---|---|---|---|---|
| LENS-1 | ☐ Yes ☐ No ☐ Mixed ☐ Not known |  |  |  |

#### Lens 1 validation and escalation

| Lens record ID / option version | Evidence follow-up or local-validation ID | Due date | Consequence / affected-action hold | Escalation route |
|---|---|---|---|---|
| LENS-1 |  |  |  |  |

### 2. Risk and control exposure.

| Required item | Workbook instruction |
|---|---|
| Assessment question | Compared with current delivery, does the proposed shared-delivery boundary keep risk and control exposure manageable without creating unacceptable concentration? |
| Action | Compare current and proposed failure events, access, concentration, continuity, safety, financial, supplier, and control exposure. |
| People to ask | Risk, Compliance, Audit, Cybersecurity, Data, Safety, Finance, current owner, delivery staff, and service customers as relevant. |
| Evidence | Incident and complaint records, risk register, access reviews, control tests, audit findings, continuity tests, recovery results, and open actions. |
| Output | A current-versus-option risk and control comparison with named owners and required treatments. |
| Escalation trigger and route | Route an unowned material risk, missing control, proposed waiver, or residual-risk acceptance to the authorized control or risk owner. |

#### Lens 2 answer and evidence

| Lens record ID | Answer for proposed shared boundary | Evidence reference and finding | Evidence limitation | Accountable owner |
|---|---|---|---|---|
| LENS-2 | ☐ Yes ☐ No ☐ Mixed ☐ Not known |  |  |  |

#### Lens 2 validation and escalation

| Lens record ID / option version | Evidence follow-up or local-validation ID | Due date | Consequence / affected-action hold | Escalation route |
|---|---|---|---|---|
| LENS-2 |  |  |  |  |

### 3. Strategic fit and differentiation.

| Required item | Workbook instruction |
|---|---|
| Assessment question | Does the proposed shared-delivery boundary preserve necessary business proximity and differentiation while supporting the organization's strategy? |
| Action | Distinguish work that supports a common strategy and work requiring proximity to a service customer, market, profession, site, or legal entity. Record why each variation exists. |
| People to ask | Sponsor, business leaders, current owner, functional specialists, site or entity leaders, and representative service customers. |
| Evidence | Approved strategy, service-customer commitments, variation records, decision history, market or site constraints, and cases requiring local judgment. |
| Output | A share, retain, or mixed boundary for each material activity, including every business-proximity requirement. |
| Escalation trigger and route | Route a disputed strategic priority, unsupported variation, or proposed movement of professional or local judgment to the relevant business and decision owner. |

#### Lens 3 answer and evidence

| Lens record ID | Answer for proposed shared boundary | Evidence reference and finding | Evidence limitation | Accountable owner |
|---|---|---|---|---|
| LENS-3 | ☐ Yes ☐ No ☐ Mixed ☐ Not known |  |  |  |

#### Lens 3 validation and escalation

| Lens record ID / option version | Evidence follow-up or local-validation ID | Due date | Consequence / affected-action hold | Escalation route |
|---|---|---|---|---|
| LENS-3 |  |  |  |  |

### 4. Scale and repeatable demand.

| Required item | Workbook instruction |
|---|---|
| Assessment question | Does the evidence show sufficient scale and repeatable demand to support the proposed shared-delivery boundary? |
| Action | Define request categories, measure demand and seasonality, sample effort, and separate ordinary work from exceptions. |
| People to ask | Delivery staff, service owner, system owner, Planning, Finance, and service customers who can confirm the demand represented. |
| Evidence | Request records, volumes by type and service customer, timestamps, backlog, time samples, peak-period records, and exception mix. |
| Output | A dated demand profile showing repeatability, variation, workload, and data gaps. |
| Escalation trigger and route | Route inconsistent categories, missing periods, unverifiable demand, or unsafe data access to the source owner and sponsor. |

#### Lens 4 answer and evidence

| Lens record ID | Answer for proposed shared boundary | Evidence reference and finding | Evidence limitation | Accountable owner |
|---|---|---|---|---|
| LENS-4 | ☐ Yes ☐ No ☐ Mixed ☐ Not known |  |  |  |

#### Lens 4 validation and escalation

| Lens record ID / option version | Evidence follow-up or local-validation ID | Due date | Consequence / affected-action hold | Escalation route |
|---|---|---|---|---|
| LENS-4 |  |  |  |  |

### 5. Coordination complexity.

| Required item | Workbook instruction |
|---|---|
| Assessment question | Is coordination manageable or improved under the proposed shared-delivery boundary without creating a more serious coordination problem? |
| Action | Locate duplicate records, queues, reconciliations, repeated approvals, unclear ownership, cross-entity dependencies, and rework. Test the cause before proposing a structural fix. |
| People to ask | Delivery staff, service customers, process owner, system owner, current owner, and owners of upstream or downstream dependencies. |
| Evidence | Case traces, queue reports, duplicate records, reconciliations, rework, unresolved escalations, dependency maps, and complaint history. |
| Output | A coordination problem map with causes, affected parties, evidence, and tests for each proposed remedy. |
| Escalation trigger and route | Route an unowned dependency, conflicting process owner, or cross-entity control issue to the sponsor and accountable owners. |

#### Lens 5 answer and evidence

| Lens record ID | Answer for proposed shared boundary | Evidence reference and finding | Evidence limitation | Accountable owner |
|---|---|---|---|---|
| LENS-5 | ☐ Yes ☐ No ☐ Mixed ☐ Not known |  |  |  |

#### Lens 5 validation and escalation

| Lens record ID / option version | Evidence follow-up or local-validation ID | Due date | Consequence / affected-action hold | Escalation route |
|---|---|---|---|---|
| LENS-5 |  |  |  |  |

### 6. Current-delivery versus shared-delivery economics.

| Required item | Workbook instruction |
|---|---|
| Assessment question | Do the comparable economics support the proposed shared-delivery boundary after transition, control, governance, retained-work, reversal costs, and evidence limitations are included? |
| Action | Compare the same service scope, period, volume, quality, and risk requirement across current delivery and each realistic option. Include retained work, transition, systems, suppliers, governance, controls, tax questions, and reversal. |
| People to ask | Finance, current owner, Human Resources, Technology, Procurement, Tax, service customers, and owners of retained work. |
| Evidence | People effort, approved cost records, supplier spend, system cost, allocation method, transition estimates, retained-work estimates, control cost, and sensitivity assumptions. |
| Output | A comparable economics table with visible assumptions, exclusions, uncertainty, and Finance confirmation. |
| Escalation trigger and route | Return the model to Finance when scope or periods differ, costs are omitted, savings depend on unsupported headcount change, or tax treatment is unresolved. |

#### Lens 6 answer and evidence

| Lens record ID | Answer for proposed shared boundary | Evidence reference and finding | Evidence limitation | Accountable owner |
|---|---|---|---|---|
| LENS-6 | ☐ Yes ☐ No ☐ Mixed ☐ Not known |  |  |  |

#### Lens 6 validation and escalation

| Lens record ID / option version | Evidence follow-up or local-validation ID | Due date | Consequence / affected-action hold | Escalation route |
|---|---|---|---|---|
| LENS-6 |  |  |  |  |

#### Economics comparison

Use the same Economics ID in both parts.

| Economics ID | Cost or value element | Current delivery | Shared option |
|---|---|---|---|
| ECO-01 | Recurring people effort |  |  |
| ECO-02 | Systems and external suppliers |  |  |
| ECO-03 | Retained local work |  |  |
| ECO-04 | One-time implementation and transition |  |  |
| ECO-05 | Governance, controls, and assurance |  |  |
| ECO-06 | Tax, charging, and intercompany effects |  |  |
| ECO-07 | Reversal and exit |  |  |
| ECO-08 | Service, customer, control, and risk effect |  |  |

| Economics ID | Source and period | Assumption or limitation | Finance confirmation |
|---|---|---|---|
| ECO-01 |  |  |  |
| ECO-02 |  |  |  |
| ECO-03 |  |  |  |
| ECO-04 |  |  |  |
| ECO-05 |  |  |  |
| ECO-06 |  |  |  |
| ECO-07 |  |  |  |
| ECO-08 |  |  |  |

### 7. Capability maturity and culture.

| Required item | Workbook instruction |
|---|---|
| Assessment question | Are capability, readiness, capacity, and culture sufficient to sustain the proposed shared-delivery boundary safely and reversibly? |
| Action | Test whether sponsorship, authority, people, process, data, systems, controls, capacity, change behavior, service-customer support, continuity, and rollback can sustain the proposed arrangement. This lens holds readiness. |
| People to ask | Sponsor and each accountable owner for the proposed service, including service customers and owners of people, systems, data, controls, and change. |
| Evidence | Process quality, data quality, capacity and skills, role clarity, system behavior, control results, open risks, change history, continuity tests, and prerequisite status. |
| Output | A readiness and prerequisite register that separates closed, open, blocking, and monitorable items. |
| Escalation trigger and route | Stop a pilot when authority, capability, capacity, control, service-customer support, continuity, or rollback is not sufficient for the bounded test. Route the gap to its owner and sponsor. |

#### Lens 7 answer and evidence

| Lens record ID | Answer for proposed shared boundary | Evidence reference and finding | Evidence limitation | Accountable owner |
|---|---|---|---|---|
| LENS-7 | ☐ Yes ☐ No ☐ Mixed ☐ Not known |  |  |  |

#### Lens 7 validation and escalation

| Lens record ID / option version | Evidence follow-up or local-validation ID | Due date | Consequence / affected-action hold | Escalation route |
|---|---|---|---|---|
| LENS-7 |  |  |  |  |

#### Readiness details

Use the same Readiness ID in both parts.

| Readiness ID | Area | Status | Evidence | Owner |
|---|---|---|---|---|
| READY-01 | Sponsorship and authority | ☐ Ready ☐ Gap ☐ Not known |  |  |
| READY-02 | Process and service ownership | ☐ Ready ☐ Gap ☐ Not known |  |  |
| READY-03 | Data and systems | ☐ Ready ☐ Gap ☐ Not known |  |  |
| READY-04 | Capacity and skills | ☐ Ready ☐ Gap ☐ Not known |  |  |
| READY-05 | Controls and specialist validation | ☐ Ready ☐ Gap ☐ Not known |  |  |
| READY-06 | Change and service-customer support | ☐ Ready ☐ Gap ☐ Not known |  |  |
| READY-07 | Continuity and rollback | ☐ Ready ☐ Gap ☐ Not known |  |  |

| Readiness ID | Required action | Blocking effect |
|---|---|---|
| READY-01 |  |  |
| READY-02 |  |  |
| READY-03 |  |  |
| READY-04 |  |  |
| READY-05 |  |  |
| READY-06 |  |  |
| READY-07 |  |  |

### Seven-Lens synthesis

Write one evidence-backed sentence for each lens. Classify its decision effect as supports, opposes, condition, or unresolved. Explain any Mixed or Not known answer. Do not count answers or calculate a total.

| Canonical lens | Answer | One-sentence finding | Main limitation | Decision effect |
|---|---|---|---|---|
| 1. Regulatory and accountability necessity. |  |  |  |  |
| 2. Risk and control exposure. |  |  |  |  |
| 3. Strategic fit and differentiation. |  |  |  |  |
| 4. Scale and repeatable demand. |  |  |  |  |
| 5. Coordination complexity. |  |  |  |  |
| 6. Current-delivery versus shared-delivery economics. |  |  |  |  |
| 7. Capability maturity and culture. |  |  |  |  |

### Worked example: one employee-letter service, two operating units

**Teaching example only.** DEMO-SS-01 concerns two operating units within one Saudi organization, not subsidiaries. Both units use the service; the employee receives the letter. All records, quantities, dates and conclusions below are invented for instruction, not the author's client experience, a Saudi benchmark or an actual approval. The date of this hypothetical assessment is 5 September 2026.

**Assignment:** assess routine salary letters using an approved template. Custom wording that adds commitments is a meaningful exception. Compare OPT-A, a common procedure executed within each unit, with OPT-B-v1, a shared team issuing both routine and customized letters. Before applying the lenses, write these boundaries down.

#### Trace the work before judging the proposal

| Case | What happens / record to inspect | Who decides / what the analyst records |
|---|---|---|
| Ordinary: routine salary letter | Receive a valid request; check the authoritative employment record; use the approved template; verify the issuing person's authority; perform the release check; deliver securely and retain the record. | The template fixes wording within its approved use. The delegation identifies who may issue for which units and letter types. Record both references, not one combined “approved” label. |
| Exception: recipient asks for a future-employment guarantee | Detect the requested wording change; document the request and reason; refer it to the authorized HR owner, with Legal where needed. Record the decision before preparing any authorized response; communicate and monitor closure. | The shared team cannot treat a routine template as authority to add a commitment. It documents, follows up and escalates. A written decision may permit it to prepare or send the specific approved response within its authority. |

#### Evidence: each record has a limit

| Teaching reference | Finding in this example | What it does not prove |
|---|---|---|
| DEMO-EVD-01: template and use conditions, confirmed by HR | Standard salary wording is approved for both units. | That the proposed team's named issuers have authority, or that customized commitments are approved. |
| DEMO-EVD-02: delegation register and owner confirmation | Named proposed issuers are covered for routine letters in both units; customized commitments are excluded. | Data quality, handling capacity, economics or coverage during absence. |
| DEMO-EVD-03: redacted ordinary and exception records | Routine requests can follow one process; custom wording needs a retained decision. A duplicated handoff can be removed. | That two traced cases establish annual volumes or every risk. |
| DEMO-EVD-04: twelve-month extract plus separate time sample | Assumed here to support 1,000 routine cases annually at 18 handling minutes each, plus 100 rework events at 6 additional minutes. Oversight requires 2,400 minutes not included in handling time. | Waiting time is not staff effort; annual totals do not establish peak or absence coverage. |
| DEMO-EVD-05: qualified review record for this exact boundary | For this teaching scenario, the relevant owners have confirmed the authority and required data, access and control conditions for routine letters. | A general Saudi legal conclusion, permission for another service or proof that those controls operate effectively. |
| DEMO-EVD-06: cost enquiry and readiness walk-through | Full comparable cost is unfinished; the proposed backup roster has not been tested. | Savings or pilot readiness. Both remain unresolved. |

Keep three delegation outcomes distinct: **covered** supports issuance authority only within that scope; **explicitly excluded** is evidence against issuance by that team under current authority; **not verifiable** is Not known and holds the affected issuance until resolved. None establishes the other conditions of a pilot.

OPT-B-v1 is too broad: DEMO-EVD-02 excludes customized commitments. Revise it to **OPT-B-v2: shared handling and issuance of routine salary letters only, with customized wording and employment decisions retained by the authorized HR owner**. Record the revision and reassess the affected lenses. The following answers apply to v2, not the rejected v1 boundary.

| Lens | Completed teaching answer for OPT-B-v2 | Reason / consequence |
|---|---|---|
| 1. Regulatory and accountability necessity | Mixed | EVD-02 and EVD-05 establish permissible routine issuance and retained accountability, but do not establish a necessity for common accountability. The legal/authority conditions do not compel central delivery. |
| 2. Risk and control exposure | Mixed | EVD-03 supports a common routine path with named release checks; retained exception decisions and control testing remain essential. No blanket transfer of HR risk. |
| 3. Strategic fit and differentiation | Yes | A common routine letter does not require a separate local wording decision; customized commitments remain close to the authorized HR owner. |
| 4. Scale and repeatable demand | Mixed | EVD-04 supports recurring work across both units, not a claim that this workload needs a separate department or a full-time post. Peak demand remains a gap. |
| 5. Coordination complexity | Yes | EVD-03 identifies a duplicate handoff the v2 boundary removes while preserving one explicit exception route. Confirm the effect during any later pilot. |
| 6. Current-delivery versus shared-delivery economics | Not known | EVD-06 lacks full comparable costs, including retained work, control, access and transition. GAP-01 prevents a savings claim and a full-rollout recommendation. |
| 7. Capability maturity and culture | Not known | EVD-06 does not establish backup and peak coverage. GAP-02 prevents pilot readiness, so the affected pilot must wait. |

| Follow-up | Accountable owner / hypothetical deadline | Action, consequence and escalation |
|---|---|---|
| GAP-01 / EVD-06 | Finance reviewer / 15 September 2026 | Compare OPT-A with OPT-B-v2 on the same annual boundary; no savings claim or full-rollout recommendation until reviewed. Escalate missed delivery to the sponsor. |
| GAP-02 / EVD-04 and EVD-06 | Service owner / 12 September 2026 | Test a roster against peaks, absence and exception handoffs; hold the two-unit pilot until readiness is demonstrated. Escalate unresolved coverage to the decision forum. |

**Capacity check:** recurring effort is 1,000 × 18 + 100 × 6 + 2,400 = 21,000 minutes a year. Illustrative productive time is 120,000 scheduled minutes less 12,000 leave, 6,000 training and 6,000 other unavailable minutes = 96,000. The ratio is **0.21875 full-time workload equivalent**, not an instruction to employ 0.22 people. Oversight was not already in handling time; leave and training were deducted once. The 4,800 transition minutes are separate one-off work. Customized letters are outside this shared boundary, so do not add their work here or pretend it disappears from the retained team's costs.

**Decision brief:** recommend OPT-B-v2 as the candidate for further assessment, keep OPT-A as the current-state comparator, reject v1's customized-letter scope, and **defer the pilot** pending GAP-02 and the decision owner's review of affordability and the proposed test. Do not claim savings. The hypothetical forum records “defer, return with cost comparison and demonstrated coverage,” with the two owners and dates above. This is a completed recommendation, not a failed assessment: it states what the evidence permits and what it does not.

In the Excel example, the active gap is coverage, the service owner owns the roster test and the due date is 12 September 2026. “Blocked by unknown” describes this unresolved route; it does not prevent the analyst from gathering evidence or completing the recommendation.
## 10. Functional boundary examples

These are fillable examples of possible boundaries. They are not definitions, Saudi legal conclusions, or instructions to move a whole function. Confirm the real boundary against current authority and specialist review.

### How to use the examples

**Write:** Replace or narrow the example activities to match the one service. Name the retained decision owner.  
**Ask:** Current owner, service customers, delivery staff, and relevant specialist owners.  
**Acceptable evidence:** Cases, delegations, policies, contracts, system records, professional obligations, and owner confirmation.  
**Produce:** A proposed shared-versus-retained boundary.  
**Stop or escalate:** Stop if a function label becomes the only reason for moving work or if authority and controls cannot be assigned.

### Human Resources example

| Possible shared boundary | Possible retained boundary | Local adjustment and evidence | Decision owner |
|---|---|---|---|
| Routine personnel requests and changes, personnel administration, payroll execution, and employee records. | Talent acquisition and recruitment decisions, organization change, workforce judgment, and workforce strategy. |  |  |

### Finance example

| Possible shared boundary | Possible retained boundary | Local adjustment and evidence | Decision owner |
|---|---|---|---|
| Accounting, bookkeeping, transaction processing, and routine financial records. | Investments, borrowing and financing decisions, capital allocation, and strategic finance. |  |  |

### Procurement example

| Possible shared boundary | Possible retained boundary | Local adjustment and evidence | Decision owner |
|---|---|---|---|
| Post-award administration, obligation and milestone tracking, expiry records, supplier follow-up, and maintenance of the approved record. | The subsidiary or accountable business owner decides the contractual response to supplier failure. |  |  |

When a supplier fails to perform, detect the failure, document it, escalate it, wait for the authorized decision, execute the approved action, communicate it, and monitor the result. Under this example, Shared Services may prepare and send an approved notice, follow up, and maintain the record after the authorized owner decides the response. A different authority configuration may delegate defined decisions when the delegation, competence, controls, and escalation are documented.

### Legal example

| Possible shared boundary | Possible retained boundary | Local adjustment and evidence | Decision owner |
|---|---|---|---|
| Legal-operations administration, including matter intake, document control, billing coordination, and records. | Negotiation, litigation, legal strategy, and multi-jurisdiction legal judgment by qualified owners. |  |  |

### Sales example

| Possible shared boundary | Possible retained boundary | Local adjustment and evidence | Decision owner |
|---|---|---|---|
| Order administration, CRM or ERP entry, fulfillment and invoicing coordination, sales records, and quotation preparation using only approved prices, terms, and authority limits. | Pricing, discounts, negotiation, customer commitments, account strategy, and commercial judgment. |  |  |

### Other context-driven services

Consider Information Technology, Marketing, Facilities, Safety and Security, and other functions only when a defined service, service-customer group, authority boundary, evidence base, and suitable form can be established.

Use the same Candidate ID in both parts.

| Candidate ID | Candidate service | Function today | Service customers | Repeatable result |
|---|---|---|---|---|
| CAN-01 |  |  |  |  |
| CAN-02 |  |  |  |  |

| Candidate ID | Judgment or retained decision | Evidence owner | Assess now? |
|---|---|---|---|
| CAN-01 |  |  | ☐ Yes ☐ No |
| CAN-02 |  |  | ☐ Yes ☐ No |

## 11. Compare authority alternatives

The three alternatives below are not a maturity ladder. Shared Services can own decisions when authority is expressly granted and controlled.

### How to complete this page

**Write:** Compare only realistic alternatives. State which decisions move, which remain, and how exceptions travel.  
**Ask:** Sponsor, decision owner, current owner, affected business leaders, service customers, and control or specialist owners relevant to the authority.  
**Acceptable evidence:** Delegations, policy ownership, reporting lines, exception records, control evidence, service maps, and mandate documents.  
**Produce:** Authority comparison with one preferred or testable alternative.  
**Stop or escalate:** Stop if an option assumes authority that cannot be delegated, hides a retained owner, lacks controls, or has no return path.

### Authority, retained decisions, and controls

| Alternative | Authority held by Shared Services | Retained decisions | Required controls | Escalation outside authority |
|---|---|---|---|---|
| A. Execution-only | Performs defined transactional work within approved rules. | Policy, priorities, material approvals, and exceptions remain with named owners. | Work instructions, access limits, evidence retention, quality checks, and timely retained decisions. | Route every case outside the approved rule to the named decision owner. |
| B. Delegated authority | Owns defined standards, routine approvals, operating decisions, or exceptions within written limits. | Decisions outside the delegation and any non-delegable duties remain with named owners. | Written delegation, competence, limits, logs, review, independent challenge, and revocation route. | Route cases beyond the limit or with changed risk to the retained owner. |
| C. Enterprise operating portfolio | Controls material priorities, resources, policies, cross-entity coordination, or operating decisions. | Board, executive, professional, legal, fiduciary, or other reserved decisions remain where required. | Enterprise mandate, governance, risk oversight, portfolio capacity, decision records, and accountability across entities. | Route reserved or extraordinary matters to the named executive or governance forum. |

### Reporting, service-customer effect, and risk

| Alternative | Reporting implications | Effect on service customers | Main risk to test | Evidence and local conclusion |
|---|---|---|---|---|
| A. Execution-only | Reporting follows operational scale, controls, dependencies, and risk. | Customers may gain one route while waiting on retained owners for exceptions. | Slow retained decisions or unclear handoffs. |  |
| B. Delegated authority | Reporting must support the materiality of delegated decisions and independent oversight. | Customers may receive faster routine decisions within clear limits. | Authority drift, weak competence, or poor escalation. |  |
| C. Enterprise operating portfolio | In the author's model of broad, decision-owning business enablement, the Shared Services chief must report directly to the CEO. This is a model-specific design judgment, not a universal legal rule attached to a title. | Customers may receive coordinated priorities across entities but can lose necessary local proximity. | Excess concentration, weak local voice, or blurred reserved authority. |  |

The reason is continuous alignment with the business, not escalation alone. When Shared Services manages and decides across the enablement infrastructure, its chief integrates the specialist departments. The CEO aligns their interdependencies with business priorities, resolves cross-business trade-offs and sponsors changes beyond the portfolio. Reporting beneath another executive with an overlapping operating mandate can duplicate authority and obscure ownership. Define the remaining COO remit, if that role exists. Limited execution-only services can sit lower because the wider business decisions remain elsewhere.

### Selected authority statement

Use this response box to synthesize the proposed authority. Keep the instructions separate from the completed statement.

| Authority statement item | What a good answer covers | Your response |
|---|---|---|
| Selected authority alternative | A. Execution-only, B. Delegated authority, C. Enterprise operating portfolio, or a precisely bounded combination. |  |
| Decisions Shared Services may make | Each decision, its scope, and the service customers or cases covered. |  |
| Authority limits | Financial, policy, risk, case, entity, service-customer, time, or other limits. |  |
| Required evidence and controls | Record needed before a decision, control performed, and evidence retained. |  |
| Review owner | Role that reviews use of authority and the review cadence. |  |
| Retained decisions and owners | Decisions that do not move and the role accountable for each. |  |
| Executive interfaces | What the Shared Services chief decides, what the CEO resolves, what any COO or other executive retains, and how overlap is removed. |  |
| Escalation route | Trigger, receiving owner or forum, required record, and response expectation. |  |
| Complete authority statement | One paragraph that joins the selected authority, limits, controls, retained decisions, and escalation. |  |

## 12. Compare organizational forms

Forms are alternatives or components. None is the definition of Shared Services, and none is automatically more mature.

### How to complete this page

**Write:** Compare the smallest forms that could carry the selected service and authority. Record why each form fits or fails the criteria below.  
**Ask:** Sponsor, decision owner, current owner, Finance, Human Resources, Legal, Procurement, Risk, service customers, and government or sector owners only where their evidence affects the form.  
**Acceptable evidence:** Workload, workforce, project portfolio, contracts, intercompany records, delegations, control requirements, legal context, business model, and service-customer evidence.  
**Produce:** A short list of viable forms with a preferred form or a form to test.  
**Stop or escalate:** Stop if the recommendation relies only on a title or subsidiary count, requires an unauthorized legal-form change, or leaves authority and control owners unclear.

| Possible form | What to test before using it | Evidence for this service | Keep, reject, or test |
|---|---|---|---|
| Common process or platform | Whether common work or records can improve without moving ownership or authority. |  |  |
| Lead department | Whether one existing department can serve others with clear accountability and capacity. |  |  |
| Internal team | Whether a small dedicated team is sufficient for the defined service. |  |  |
| Department | Whether workload, ownership, controls, and management span justify dedicated departmental accountability. |  |  |
| Division | Whether several related departments or material coordination needs require a divisional layer. |  |  |
| Second-level unit under Operations or another portfolio | Whether limited authority and risk can be carried within an existing portfolio while retained decisions and escalation remain clear. |  |  |
| Executive portfolio | Whether material enterprise authority, resources, policy, and cross-entity decisions require senior executive accountability. |  |  |
| Group unit | Whether group-wide service customers, intercompany coordination, authority, and controls support a group arrangement. |  |  |
| Separate company | Whether scale, workforce, projects, independent contracting, financial coordination, controls, risk, legal context, and business model justify incorporation. |  |  |
| Government instrument | Whether the service customers and mandate fit an authorized Saudi government arrangement. |  |  |
| Deliberate combination of forms | Whether one container is insufficient and a specific combination, such as a common platform, lead department, and specialized team, assigns ownership and authority more clearly. |  |  |

Multiple subsidiaries alone are insufficient evidence for a separate company. Complete the form criteria before recommending any structure.

| Form criterion | Current evidence | Decision effect | Owner or specialist review |
|---|---|---|---|
| Workforce and leadership span |  |  |  |
| Project size and portfolio |  |  |  |
| Demand, transaction, and coordination volume |  |  |  |
| Independent contracting need |  |  |  |
| Intercompany financial coordination |  |  |  |
| Policy and decision authority |  |  |  |
| Risk, controls, and assurance |  |  |  |
| Business model and customer base |  |  |  |
| Legal, government, and sector context |  |  |  |
| Reversibility and exit |  |  |  |

## 13. Draft the service boundary

### How to complete this page

**Write:** Convert the preferred authority and form into a testable service statement.  
**Ask:** Sponsor, current owner, service customers, decision owners, system owner, and relevant specialists.  
**Acceptable evidence:** Completed maps, delegations, customer obligations, policies, system constraints, control records, and local validations.  
**Produce:** Draft service boundary and governance statement.  
**Stop or escalate:** Stop if a decision has two owners, no owner accepts accountability, the performer lacks capability or access, or records and work cannot return safely.

| Element | Draft record |
|---|---|
| Service purpose and result |  |
| Service customers and eligibility |  |
| Valid request and required inputs |  |
| Included ordinary and exception work |  |
| Exclusions |  |
| Authority granted to Shared Services |  |
| Retained decisions and owners |  |
| Controls and control owners |  |
| System of record |  |
| Measures and evidence retained |  |
| Customer responsibilities |  |
| Complaint and escalation route |  |
| Dependencies and specialist conditions |  |
| Review, stop, and rollback route |  |

### Capacity: use annual units and an explicit boundary

Open the Capacity tab in the [Services Ledger](https://media.alkulaib.io/11a6815b-c41f-465e-8ef2-b142836fc729.xlsx). Column C is your case; column D is a separate hypothetical example, not default data. Enter the service ID, boundary and annual period first. Required numeric inputs need an explicit zero when genuinely zero; a blank remains unknown. Record the source, period and confirming owner alongside the inputs.

- Count routine and exception cases separately. Exception effort is the full effort for exceptions excluded from the routine count; rework is additional effort not already in either handling time.
- Add recurring leadership or control minutes only if they are outside measured handling time. Keep transition effort separate from recurring work.
- Deduct leave, training and other unavailable time once from annual scheduled time. Do not also add an absence percentage to the resulting workload ratio.
- Compare the workload equivalent with peak demand, required cover, skills and retained work. These may change the staffing arrangement; they are not automatic additions to the formula. Do not round the ratio up into approved headcount.

The example returns 21,000 recurring minutes / 96,000 productive minutes = 0.21875 workload equivalent. Coverage remains unproved, so a calculated ratio does not release the pilot hold. This is an initial capacity check; the later business-case work must examine comparable cost, funding and the feasible staffing arrangement.

### Measurement definitions

Give each measure a stable ID and use it in the pilot record. Agree definitions before comparing results.

| Measure ID / service ID | Definition, denominator and start/end points | Baseline, period and source | Target or continuing limit / measurement cadence | Data owner / review owner / consequence |
|---|---|---|---|---|
| MEAS-01 |  |  |  |  |
| MEAS-02 |  |  |  |  |

Distinguish elapsed turnaround from staff handling minutes. For accuracy, define whether you count corrections, all errors or another named condition, and use the same denominator before and during the pilot.

### Technology and change notes

Inspect the current process before proposing a system. The fields below are sufficient for this starting assessment; they do not authorize procurement or a live change.

| Technology question | Evidence / gap reference | Owner / next action / due date | Effect on the proposed boundary or pilot |
|---|---|---|---|
| Authoritative data, access and release permission |  |  |  |
| Handoffs, audit trail, security and continuity controls |  |  |  |
| Current-system constraint / whether process change alone is enough |  |  |  |

| Affected role or service customer | What changes and what remains | Readiness evidence / communication or training required | Owner / due date / unresolved consequence |
|---|---|---|---|
|  |  |  |  |

## 14. Recommendation, no-change option, and bounded pilot

The brief must fit one decision forum, even if supporting registers are attached. A recommendation may be a bounded pilot, another arrangement, a targeted current-state fix, more evidence, or no change.

### How to complete this page

**Write:** Use the completed registers and comparisons to make one bounded recommendation with visible limits.  
**Ask:** Source owners confirm material facts; accountable specialists close or condition their validation items; the sponsor routes the brief to the decision owner.  
**Acceptable evidence:** Confirmed records, reproducible calculations, completed case traces, owner confirmations, and unresolved items stated with their decision effect.  
**Produce:** One-page decision brief plus a pilot record or no-change record when applicable.  
**Stop or escalate:** Do not recommend implementation while a material authority, legality, control, safety, data, cyber, workforce, finance, procurement, tax, or sector prerequisite remains blocking.

### One-page decision brief

Write in the `Your response` column. Keep the quality prompt intact for the reviewer.

| Section | What a good answer covers | Your response |
|---|---|---|
| Decision requested | Exact decision the forum must make. |  |
| Service problem or opportunity | Evidence-backed problem or opportunity, affected service customers, and period. |  |
| Strongest evidence and limitations | Strongest confirmed, observed, or calculated evidence, plus material limits, disputes, and unknowns. |  |
| Seven-Lens synthesis without a score | All seven lenses and which findings support, condition, or oppose the proposed boundary. Do not count answers. |  |
| Options considered | Current state, smallest credible alternatives, authority alternatives, and plausible forms. |  |
| Retained decisions | Every decision that stays outside Shared Services and its owner. |  |
| Proposed authority | Selected authority alternative, exact limits, controls, and escalation. |  |
| Proposed form | Selected form or combination and why its scale and context fit. |  |
| Saudi validations | Confirmed, pending, disputed, and blocking legal, regulatory, cyber, data, tax, procurement, workforce, finance, and sector items. |  |
| Recommendation | Bounded pilot, another arrangement, targeted fix, more evidence, or no change, with the evidence-based reason. |  |
| Bounded pilot | Service, service customers, duration, included cases, exclusions, authority, people, systems, and prerequisites. Record not applicable when no pilot is proposed. |  |
| Success conditions | Measurable conditions and evidence sources that would support continuation. |  |
| Stop conditions | Events that require pause or termination. |  |
| Rollback conditions and route | How work, records, access, knowledge, and accountability return safely. |  |
| Decision owner | Person or forum authorized to decide. |  |
| Next review date | Date, purpose, and evidence expected at the next gate. |  |

### Bounded pilot record

| Pilot field | Approved record |
|---|---|
| Service and service customers |  |
| Duration and operating calendar |  |
| Included volume or case types |  |
| Exclusions and retained decisions |  |
| Authority and limits |  |
| People, systems, and channels |  |
| Closed prerequisites |  |
| Evidence captured |  |
| Success conditions |  |
| Stop conditions |  |
| Rollback, knowledge, access, and record-return route |  |
| Decision meeting and owner |  |

### No-change record

Complete this table when evidence does not justify intervention or when another current-state remedy is sufficient.

| No-change question | Evidence-backed answer |
|---|---|
| Which service problem remains? |  |
| Why does a Shared Services change lack sufficient mandate, evidence, benefit, readiness, or control? |  |
| Which targeted current-state action, if any, should occur? |  |
| Which risk or limitation remains accepted, and who has authority to accept it? |  |
| What new evidence or event should reopen the assessment? |  |
| Who owns the next review and on what date? |  |

### Pilot measurement and decision record

Complete this record before seeking permission to start. A desired improvement and a condition that must remain satisfied are different things. A faster service does not compensate automatically for worse accuracy or a failed control.

| Record | Required entry | Your response |
|---|---|---|
| Pilot identity | Service ID, option version, units, included cases, dates and excluded work. |  |
| Permission and prerequisites | Decision owner, authority reference, each prerequisite, closure proof and date. A proposed pilot is not an approved pilot. |  |
| Intended improvement | Measure ID, baseline and period, target, measurement source and review date. |  |
| Continuing conditions | Accuracy, authority, access, control, continuity and other relevant limits; measurement and owner for each. |  |
| Stop or narrow trigger | Breach or unknown that stops affected work; who can act and who receives escalation. |  |
| Continuity and rollback | Safe return path, retained-team capacity, owner and time to restore service. |  |
| Result and decision | Comparable results, exceptions, remaining gaps and the authorized continue, revise, stop or defer decision with date/reference. |  |

**Separate hypothetical illustration:** suppose a later authorized trial reduces median turnaround from two working days to one, but correction-free letters fall from 99% to 95%. If the agreed continuing accuracy floor was 99%, the speed target is met but the pilot does not pass. Invoke the agreed hold or rollback, investigate errors, and return to the authorized reviewer. These figures illustrate a decision rule; they are not observed results from DEMO-SS-01 or recommended universal targets.

## 15. Decision-quality and completion checks

Reject the recommendation and return it for evidence when any of the following is the only justification:

- a department label;
- a job title;
- the number of subsidiaries;
- an unverified benefit, savings, speed, control, customer, or headcount claim.

**Write:** Record the result of every check, every condition, and the final decision reference.  
**Ask:** Analyst completes the first gate; sponsor and decision owner complete the second. Ask a specialist only about an item within that specialist's remit.  
**Acceptable evidence:** The completed workbook, cited source records, confirmation messages, validation decisions, and the authoritative forum record.  
**Produce:** A recorded quality decision and next review gate.  
**Stop or escalate:** Return the brief when any required check is incomplete or when the forum lacks authority for the proposed action.

### Analyst completion check

| Check | Result |
|---|---|
| Sponsor confirmed the assignment and decision forum. | ☐ Complete ☐ Return |
| One service and its service customers are defined. | ☐ Complete ☐ Return |
| The analyst stayed within granted authority. | ☐ Complete ☐ Return |
| Main claims have sources, owners, periods, quality labels, and limitations. | ☐ Complete ☐ Return |
| Every unknown has an owner, deadline, consequence, escalation and correct route; readiness-blocking operational gaps hold the affected pilot. | ☐ Complete ☐ Return |
| Confirmed non-applicability has a reason, qualified reviewer and scope, not a blank or fifth lens answer. | ☐ Complete ☐ Return |
| One ordinary case and one meaningful exception were traced. | ☐ Complete ☐ Return |
| The responsibility map uses detect, document, escalate, decide, execute, communicate, and monitor. | ☐ Complete ☐ Return |
| All seven canonical lenses are complete and no total score exists. | ☐ Complete ☐ Return |
| Business proximity is handled inside lens 3. | ☐ Complete ☐ Return |
| Readiness is handled inside lens 7. | ☐ Complete ☐ Return |
| Shared Services authority and retained decisions are explicit. | ☐ Complete ☐ Return |
| Sourcing remains a separate decision. | ☐ Complete ☐ Return |
| The proposed form is supported by more than a title or subsidiary count. | ☐ Complete ☐ Return |
| Saudi specialist questions have accountable owners. | ☐ Complete ☐ Return |
| The recommendation includes another arrangement or no change when justified. | ☐ Complete ☐ Return |
| Any pilot distinguishes improvement targets from continuing conditions, with defined baselines, sources, owners, stop triggers and rollback. | ☐ Complete ☐ Return |
| Capacity uses one annual boundary, avoids double counting and checks peaks and cover separately. | ☐ Complete ☐ Return |

### Sponsor and decision-owner gate

| Decision | Selection and record |
|---|---|
| Assessment quality | ☐ Accept evidence for decision ☐ Return for correction ☐ Request more evidence |
| Recommendation | ☐ Approve within authority ☐ Reject ☐ Narrow ☐ Defer ☐ Select another arrangement ☐ No change |
| Conditions | Write every condition, owner, due date, and blocking effect. |
| Decision record | Record the forum, date, attendees required by governance, and authoritative evidence reference. |
| Next review | Record the date, owner, and required evidence. |

The analyst stops here. Implementation, sourcing, organizational change, legal-form change, publication, and live-system changes require separate authority and their own controls.