The process was documented, the responsibilities were defined, the TAT existed, the checklists existed, and the enterprise systems existed. Yet the process remained difficult to manage at scale. Information moved across email, Teams, WhatsApp, shared drives, departmental trackers and individual follow-ups. Multiple internal teams and external stakeholders interacted at different points in the journey. Documents changed hands repeatedly, and activities depended on preceding approvals. When something was delayed, it was often difficult to determine exactly where the delay had occurred, how long it had remained there, and who was accountable for the next action.

Crizzen was engaged to study this operating model and design an automation blueprint that could turn the SOP from a reference document into a live, measurable and system-led process. The resulting solution combined workflow orchestration, document intelligence, process monitoring, AI agents, enterprise integrations and management dashboards into a single target-state operating model.

The engagement covered discovery and solution design. The solution described here was not yet deployed at the time of writing.

Download The Case Study

01. The business context

For a real estate developer, the fit-out journey begins well before construction starts. A prospective tenant or brand first enters discussions with the leasing team. Commercial terms are negotiated, initial documentation is exchanged, approvals begin, financial obligations are completed and multiple internal functions are brought into the process.

Once the space is ready for handover, the journey expands further. Designs need to be submitted and approved, technical disciplines need to be reviewed, and compliance requirements need to be satisfied. Contractors need to be on-boarded, site activities need to be monitored, and safety controls need to be followed. Inspections, testing and rectifications need to be completed. The process only concludes once the space is ready for commercial operations and the necessary completion, billing and revenue processes can begin.

In other words, the process is not a single fit-out activity. It is a multi-stage operating journey connecting Leasing, Legal, Finance, Design, Facilities Management, Projects, Brand/tenant, Fit-out teams, Retail Operations, Compliance, Site execution, Handover, and Revenue commencement.

The detailed operating design maps this journey into four major phases: Pre-Fit-Out, Design and Approvals, Execution and Safety, and Close-Out and Revenue. The more detailed architecture breaks this into 41 individual process steps, with each step carrying its own owner, TAT, documentation or checkpoint requirements. The intended fit-out window was approximately 90 days, although the broader pre-fit-out through post-fit-out lifecycle contained activities extending beyond that window.

02. The problem was not the absence of an SOP

The organization already had an SOP. It defined the activities to be completed, the sequence of activities, the relevant stakeholders, expected turnaround times, documentation requirements, approvals, checkpoints, responsibilities, and escalation mechanisms.

The issue was that the SOP largely described what should happen. The operating environment did not provide a unified mechanism for continuously showing what was actually happening. This distinction became the starting point for Crizzen’s discovery.

The real challenge

The process depended on multiple teams and parties coordinating correctly at each handoff, yet the underlying information was fragmented. Leasing might maintain one tracker, projects another, and facilities another. Other departments had their own checklists and formats. Communication happened across email, Teams, WhatsApp and calls, while documents were exchanged through email and shared repositories.

Weekly meetings became the mechanism for bringing these fragments together. The result was a process that was documented centrally but executed in a distributed manner.

03. What the current-state process looked like

The operating model was predominantly built around familiar enterprise tools rather than a specialized workflow application. The technology environment already included Microsoft tools such as Teams, SharePoint and Power Automate, alongside other enterprise applications used by different functions.

The problem was not a complete absence of technology. It was the absence of an orchestration layer connecting the technology, people, information and process logic.

A typical information path could therefore look like a task becoming due, someone sending an email, another person responding, and a document being attached. The receiving team would update its own tracker, a third team would be informed, a meeting would be held to reconcile status, the master position would be manually updated, and management would finally see the status in the weekly review.

This creates several points where information can become delayed, duplicated or missed. With hundreds of messages arriving across teams, an important status email could easily become one of many messages competing for attention.

04. The accountability problem

One of the most important findings from the discovery was that delay itself was not necessarily the only problem. The larger problem was proving where the delay occurred.

When a process exceeded its intended TAT, several parties could be involved. A document might be awaiting submission, a reviewer might be waiting for clarification, or an approval might depend on another team. An external party might not have responded, or a system update might not have been completed. A downstream team might therefore be waiting without having visibility into the preceding dependency.

Because there was no common event history covering the full process, resolving the issue could turn into a debate about who was responsible. The operating model therefore created what can be described as an accountability gap at process handoffs.

Crizzen’s design objective was to replace this ambiguity with an auditable chain of events: what happened, when did it happen, who owned the step, what was required, what was submitted, who reviewed it, what happened next, and was the TAT met.

05. Management visibility was retrospective

The business already had weekly governance mechanisms. Teams prepared Excel trackers, discussed ongoing projects and reconciled status during review meetings.

The problem was the time required to create that visibility. Teams spent substantial effort maintaining trackers and preparing for weekly meetings, followed by additional time in the meetings themselves. The reporting process was therefore consuming time that could otherwise have gone into execution.

More importantly, the resulting view was largely retrospective. It answered what happened last week, but it was much harder to answer what is likely to become a problem this week. That difference shaped the proposed architecture. Crizzen designed the future-state solution around continuous process monitoring rather than periodic status reporting.

06. The design principle

Crizzen approached the engagement around one central idea: the SOP should become the system of action, not just the system of record.

That meant translating the SOP into a digital process model where each activity could be represented as a structured state with an owner, action, input, output, TAT, dependency, evidence, next action, and escalation rule.

The architecture therefore treats process, steps, documents, review events and escalations as connected objects rather than separate records. This created the foundation for everything that followed.

07. Rebuilding the journey as a digital process

The 41-step workflow was organized into four major stages.

Phase 1: Pre-Fit-Out

The process starts before physical fit-out activity begins. The early stage covers commercial onboarding and stakeholder alignment, including activities such as the creation and organization of the process record, initial commercial documentation, internal approvals, financial verification, communication to relevant functions, stakeholder kick-off, legal documentation, lease and CAM processes, financial clearances, possession, fit-out documentation, insurance and compliance, and joint site readiness activities. The objective is to establish a controlled transition from commercial agreement to a fit-out-ready state.

Phase 2: Design and Approvals

Once the process reaches design and technical submission, multiple disciplines become active. The workflow encompasses areas including architectural, electrical, fire and life safety, HVAC, plumbing, and structural. Each discipline brings its own submission, review and approval dependency.

Instead of treating these as isolated emails, the proposed workflow models them as structured process steps with explicit ownership and status. The detailed architecture also recognizes that design activities can run in parallel with other parts of the pre-fit-out process, rather than forcing the entire journey into a simple serial sequence.

Phase 3: Fit-Out Execution, Safety and Monitoring

Once the space moves into execution, the process becomes more operationally intensive. The workflow needs to account for site handover, work-rule communication, contractor and workforce controls, safety briefings, work permits, debris management, common-area protection, testing, periodic HSE/MEP reviews, and ongoing tenant/brand coordination.

Some activities happen once, while others repeat throughout the execution period. Some are triggered by specific events, and others are time-bound recurring controls. This is precisely the type of environment where a static checklist becomes difficult to manage and where workflow automation can provide significant control. The detailed solution architecture models execution activities, TATs, stakeholders and escalation logic as part of one connected process.

Phase 4: Close-Out and Revenue

The final stage is more than a construction close-out because the space must transition into an operational state. That involves activities such as final debris clearance, as-built documentation, testing and verification, signage alignment, snag rectification, final completion certification, final system updates, and commencement of billing/revenue activities.

This creates an important business connection where fit-out completion leads to operational readiness, followed by handovers, and finally revenue commencement. The proposed operating model therefore treats the final phase as a revenue-enabling process rather than simply a project completion checklist.

08. From responsibility lists to executable accountability

A key part of the redesign was making ownership explicit at every stage. The workflow architecture distinguishes between the broader process owner and the individual or action owner responsible for completing a specific activity.

This enables the system to answer who owns this process, who needs to act now, what exactly needs to be done, what evidence is required, when it is due, and what happens after completion.

Instead of relying on someone remembering to send the next email, completion of one step can automatically activate the next relevant step. The proposed process engine assigns the responsible SPOC, starts the appropriate TAT clock, records completion and activates downstream activity. That turns accountability from a meeting discussion into a process attribute.

09. Connecting documents to the workflow

The second major design principle was that a document should not exist outside the process that depends on it.

In the current environment, important information could be embedded within email conversations and attachments. That makes it difficult to answer basic questions such as which version is current, who submitted it, who has reviewed it, how many times has it been reviewed, is approval pending, has the document triggered the next action, and how long has it been waiting.

Crizzen’s proposed architecture therefore connects each document to the process step that generated or requires it. The data model captures document identity, version, reviewer information, approval information and related process references. This converts document management from a repository function into a process-control function.

10. Introducing document intelligence

This is where AI becomes operationally useful rather than decorative. The proposed architecture uses Azure AI Document Intelligence to process relevant documents and extract structured information from them. The design includes capabilities such as:

Field extraction: Relevant information can be extracted from uploaded documents and converted into structured process data.

Confidence scoring: High-confidence extraction can move into the workflow automatically, while low-confidence outputs can be routed for human review.

Document comparison: Information from different document versions can be compared to identify potential discrepancies.

Review tracking: The system can retain who reviewed a document and when.

Instead of the sequence moving manually from a document to a human reading it, to a human updating a tracker, the target model becomes: document, AI extraction, system validation, human exception review, and workflow progression.

11. Adding an intelligence layer

Once process, document and event data are structured, the platform can start answering questions that were difficult to answer previously. The proposed AI layer includes capabilities such as document summarization to generate concise summaries for relevant stakeholders, risk flagging to identify clauses or document elements that may require attention against predefined standards, and meeting intelligence to convert meeting transcripts into decisions, action items and owners.

It also enables process analysis to examine the event history to identify probable causes of delay, and natural-language queries to allow authorized users to ask the platform questions about current process status. The architecture specifically envisages Azure OpenAI being grounded against live operational data so that conversational queries can be answered using the current process state.

12. Moving from workflow automation to agentic monitoring

Traditional automation answers the prompt to do Y when X happens. The proposed architecture adds another layer: continuously observe the process and identify what requires attention.

This is the role of the agentic layer. The solution design included purpose-built AI capabilities for monitoring commercial milestones, document workflows and process risks. The detailed architecture describes agents such as DealWatch, DocTrack and RiskRadar, covering milestone monitoring, document reviews, TAT breaches, missing documentation and process risks. These agents are not intended to replace people. They are designed to reduce the amount of process monitoring people have to perform manually.

13. A process that watches itself

Consider a simplified example. A process step is assigned to an individual, and the system records the expected completion time. The person receives a task, a document is uploaded, and the system records the upload. The document is routed to the relevant reviewer, the reviewer receives the task, and the TAT clock continues.

If the document remains pending, the system knows. If the deadline approaches, the system knows. If the deadline is breached, the system knows. If a downstream activity is blocked, the system knows. Instead of a manager discovering the problem during the next weekly meeting, the exception can surface while the process is still in motion. That is the operational transition Crizzen was designing.

14. The TAT control layer

TAT was one of the central requirements of the engagement. The intended process target was approximately 90 days, but the important challenge was not simply measuring total duration. The system needed to understand where time was being consumed.

The architecture therefore tracks step-level TAT, expected versus actual completion, and escalation states. The proposed monitoring model can support questions such as which stage is consuming the most time, which steps are currently overdue, which teams have recurring SLA breaches, how long a particular activity has been waiting, which delays are blocking downstream activity, and what the likely reason is for the delay. The proposed dashboard explicitly includes actual versus target TAT, delayed steps, SLA breaches and process timelines.

15. The accountability trail

A major benefit of the target architecture is the creation of an event history. Every meaningful activity can become an event: created, assigned, submitted, reviewed, rejected, revised, approved, escalated, and completed.

Each event can carry a timestamp and relevant context. The architecture includes an immutable audit log capturing process events, as well as a dedicated escalation structure. That changes the nature of accountability. Instead of asking who caused the delay, the organization can ask at which step the process stopped progressing, what action was outstanding, who owned that action, and how long it remained unresolved.

The distinction is important. The purpose is not to create another mechanism for assigning blame. It is to create enough evidence to manage accountability objectively.

16. Integrating the existing enterprise ecosystem

Crizzen did not approach the problem by replacing the client’s existing systems. The proposed architecture instead acts as an orchestration layer connecting the systems already used across the process.

The detailed architecture includes integrations across areas such as contract lifecycle management, e-signature, ERP/finance, CRM, document management, enterprise collaboration, and project/construction systems.

The logic is straightforward. Keep systems of record where they already exist, connect them through a process layer, and create one operational view of the journey. This reduces the need for teams to continuously reconcile information manually between applications.

17. The integration layer

At the center of the proposed architecture is an integration and orchestration layer built around Microsoft and Azure services.

The architecture uses Power Automate for departmental workflow automation, Azure Logic Apps for stateful process orchestration, Azure Functions for event processing, webhooks and lightweight processing, API Management as an integration layer for external APIs, Azure SQL and Microsoft Fabric for process and analytics data, and SharePoint and Microsoft 365 for document and collaboration workflows.

Detailed architecture explicitly separates process orchestration from data storage and intelligence, allowing each layer to evolve without forcing the whole system to be redesigned.

18. Creating a process data model

One of the less visible but most important parts of the proposed solution is the underlying data model. Instead of storing information primarily in spreadsheets, the platform creates structured relationships between the process, the step, the document, the review event, and the escalation.

This allows the platform to understand the relationship between what is happening and why it matters. For example, a document is not simply uploaded. It is uploaded for a particular step, belongs to a particular process, has a specific version, may have multiple review events, and can affect the activation of the next step. That relational structure is what allows analytics, automation and AI to operate on the same process foundation.

19. Management control tower

The proposed Power BI layer turns the underlying process data into an enterprise control tower. Rather than creating another manually updated MIS, the dashboard can derive its information directly from the operational data layer.

The intended views include process visibility to see how many processes are active, which phase each process is in, and how many have been initiated recently. It covers TAT and SLA tracking to measure the average TAT by step, identify which activities are taking the longest, and see where SLA breaches are occurring. Document visibility highlights which documents are outstanding, uploaded, awaiting review, and how long they have remained pending. Finally, risk and exception management identifies which mandatory items are missing, which processes are blocked, which approvals are overdue, and which issues have escalated.

These categories are directly reflected in the proposed dashboard design.

20. From dashboards to conversations

Dashboards provide visibility, while the proposed Copilot layer provides accessibility. Instead of every stakeholder learning the entire reporting interface, authorized users can interact with the process in natural language.

A manager could ask which active processes are approaching their TAT, what is currently pending with a particular function, which documents are awaiting review, which processes have been blocked for more than the expected time, or what the main causes of delay are this month.

The architecture positions Copilot and conversational AI as an interaction layer over enterprise intelligence rather than as an independent chatbot. Crizzen’s broader SCALE-AI framework similarly treats conversational interfaces as the layer through which users interact with contextual enterprise intelligence.

21. Human-in-the-loop by design

A key principle of the solution is that automation should remove coordination overhead without removing necessary human judgement. The proposed design therefore creates clear boundaries.

The system can automate task assignment, notifications, TAT tracking, workflow transitions, escalations, data capture, document routing, and routine reporting.

AI can assist with document extraction, summaries, discrepancy detection, risk flagging, meeting action extraction, root-cause analysis, and natural-language querying.

Humans remain responsible for approvals, exceptions, judgement-intensive reviews, commercial decisions, legal decisions, technical decisions, and final accountability. This makes the solution a human-led operating model augmented by automation and AI, rather than a fully autonomous process.

22. Designing for security and governance

Because the process handles commercially and operationally sensitive information, architecture incorporates security into the solution rather than treating it as an afterthought.

The proposed design includes controlled identity and access, centralized credential management and structured audit logging. Azure Key Vault is proposed for protecting credentials and tokens integration, while the platform maintains process and event records for auditability.

This supports three important requirements: only authorized stakeholders see relevant information, sensitive credentials are not embedded directly into workflow logic, and important process actions remain traceable.

23. Designing the MVP pragmatically

The architecture was also evaluated from an implementation-cost perspective. Rather than assuming that every enterprise-grade Azure component was necessary from day one, Crizzen assessed what was appropriate for an MVP.

The infrastructure analysis evaluated Azure SQL, Cosmos DB and Fabric as potential data platforms and identified Azure SQL as a cost-efficient MVP option for the expected initial data volumes, while retaining a path toward Fabric for a larger-scale implementation. Similarly, the MVP infrastructure approach prioritized consumption/basic tiers where possible, a service-account model and reuse of the existing Microsoft 365 environment.

This is important because enterprise automation does not have to begin with enterprise-scale infrastructure everywhere. The architecture can start proportionately and expand with adoption and process volume.

24. What the target state changes

The transformation can be summarized in one view.

25. What success would look like

Because the solution had not yet been implemented, Crizzen did not claim deployment outcomes. Instead, the target-state business outcomes were defined around the problems identified during discovery.

Better accountability ensures every significant process step has an identifiable owner, timestamp and status. Better visibility means management can see active processes and bottlenecks without waiting for a weekly meeting. Better coordination allows handoffs to become system-led rather than dependent on individual follow-up, while better document control ensures documents, reviews and approvals become part of the process history.

Better TAT management means the organization can monitor the journey at step level rather than only at end-to-end completion, leading to faster issue detection where potential bottlenecks can surface before they become major downstream delays. Better governance gives the organization an auditable trail of process events and responsibility. Ultimately, better tenant and brand experience emerges because a more coordinated internal process reduces avoidable waiting and uncertainty for external stakeholders, resulting in faster handover and revenue commencement.

26. The broader opportunity

The real opportunity extends beyond fit-out. Once the organization has a common pattern for process, data, workflow, AI, and governance, the same approach can be applied to other complex enterprise SOPs.

The architecture becomes reusable. A new process can be modeled through the same building blocks: define the process, create the data model, orchestrate the workflow, integrate existing systems, add intelligence where useful, monitor exceptions, measure outcomes, and scale.

This is consistent with Crizzen’s broader 4D approach of Define, Design, Develop and Deploy tailored enterprise AI solutions around business pain points and existing enterprise ecosystems.

27. Crizzen’s role

Crizzen’s involvement in this engagement was centered on the discovery and design layer.

The work covered stakeholder and process understanding to see how the existing SOP operated across departments. It involved process mapping to break a complex end-to-end journey into structured steps, dependencies and handoffs. Automation opportunity identification determined which activities should be system-driven, which required human judgement and where AI could add value.

The target-state operating model mapped how the future process should operate, while the technology architecture mapped the process to data, workflow, AI and integration components. AI architecture defined where document intelligence, agents and conversational AI could be embedded, and management visibility designed the control-tower and reporting layer. Finally, the implementation roadmap translated the future-state design into a phased path toward implementation.

This is consistent with the original engagement scope, which focused on stakeholder interviews, process mapping, pain-point identification, automation feasibility, solution direction and a phased roadmap.

28. The outcome of the engagement

The output was not another tracker. It was a blueprint for turning a complex, manually coordinated SOP into an intelligent operating process.

The proposed solution connects people, processes, documents, data, enterprise systems, automation, AI, and management intelligence into one operating model. The deeper transformation is therefore not simply automating the fit-out process. It is making the entire journey measurable, accountable, observable and progressively intelligent. That is the layer Crizzen designed.

29. Implementation status

This case study describes discovery and solution-design engagement. Crizzen designed the target operating model, process architecture, workflow logic, data structures, AI capabilities, integrations, dashboards and implementation approach.

Conclusion

Enterprise automation rarely fails because an organization has no process. It fails because the process lives in too many places.

An SOP may define the workflow, an email may contain the latest instruction, a spreadsheet may contain the current status, a shared drive may contain the document, a meeting may contain the real discussion, and someone’s memory may contain the missing context.

Crizzen’s approach was to bring those pieces into one operating model. When a process moves forward, the system knows. When a document arrives, the system knows. When responsibility changes, the system knows. When a TAT is approaching, the system knows. When something is stuck, the system knows. And when management asks what is happening, the answer does not have to wait for the next weekly meeting.

SOP becomes the workflow, the workflow becomes data, the data becomes intelligence, and the intelligence drives action.

Download The Case Study