Operations

The Operations module is where the work your business delivers actually gets done. It takes a request in at one end, turns it into a project, a task, a work order or a support ticket, tracks the effort against it, and turns the delivered work into money owed at the other end. Because it sits on the same foundation as CRM and Accounting, the invoice you raise here is a real CRM invoice, the client is the same customer record you use everywhere, and the costs land in the ledger without a second keying.

This guide is a reference for what the module does and how the pieces fit together. It describes IXL CORE version 1.0.

Overview

Operations is a broad module. At a glance it covers:

• Command centre — a single operational read across projects, work, tickets and requests.
• Intake — a request queue that triages incoming work and converts it into the right record.
• Projects — the client work you plan, staff, deliver and bill, with phases, milestones, roles, risks, issues and status reports.
• Tasks — the units of work, with assignees, priorities, dependencies and a status flow.
• Work orders — field and site jobs with checklists, materials, scheduling and evidence.
• Service desk — support tickets with SLAs, queues, teams, macros and a public portal.
• Service contracts — retainers and coverage that sit behind ticket billing.
• Billing & rate cards — billable lines, rate resolution and CRM invoice requests.
• Attendance — field punches, devices, passkeys and CSV import feeding timesheets.
• Governance, knowledge & directory — risk/issue/decision registers, a knowledge base and a shared directory.

Everything is scoped to your company, entity and branch, and every action is governed by permissions (see Access & permissions).

Command centre

The command centre gives an operational summary in one place — the shape of live projects, open work, tickets in flight and requests waiting to be triaged. It can also produce a written digest so a manager can see, in plain language, what needs attention across the module without opening each area in turn.

Intake

Work usually starts as a request. You define request types for the kinds of work you take in, and each request carries a subject, description, priority and requester. A request follows a clear lifecycle — it is submitted, triaged, then accepted or rejected, assigned and finally converted. On submission the module runs a duplicate check so the same issue is not opened twice.

The important step is convert: an accepted request becomes the right kind of record — a project, a task, a work order or a support ticket — carrying its detail across so nothing is re-typed. Requests can route through the platform’s shared approval engine where the work needs a sign-off before it proceeds.

Projects

A project is a piece of client work you plan, staff, deliver and bill. Each project carries a name, a client (a CRM account), a billing type — fixed price, time-and-materials or milestone-based — a currency, a labour rate reference and a project manager. It also tracks health, percent complete and start, target and actual-end dates. Projects move through a controlled status lifecycle and the transitions are enforced, so the state of every job stays clear.

A project is more than a header. It breaks down into:

• Phases — the stages the work moves through.
• Milestones — the billable deliverables, each with a due date, a billing amount and an acceptance step that can be routed for approval; an accepted milestone is what becomes eligible to bill.
• Roles — the team on the project, added with a role and removed without losing history.
• Risks and issues — a per-project register, each entry raised, updated and rolled into the project’s health.
• Status reports — periodic write-ups of where the project stands.

A project also exposes timesheets (the effort logged against it) and a health view that reads budget and delivery signals together, so the project manager can see at a glance whether the job is on track.

Tasks

A task is a unit of work. Each has a title, an owner (it can belong to a project, a ticket, a work order or stand alone), an assignee, a priority, a due date and a source. Tasks move through a status flow — open, in-progress and complete — and support dependencies, so one task can be marked as waiting on another. Tasks are created directly, spun off from tickets and work orders as fulfilment or follow-up steps, or generated from governance actions and meeting notes.

Work orders

A work order is a field or site job — the kind of work that happens away from a desk. Each carries a title, a category, a billing type, a priority, a site and location, a requester and customer, required skills, and a scheduled start and end. Work orders support:

• a checklist of steps to complete on site,
• a list of materials used on the job,
• evidence capture (for proof of work),
• follow-up tasks, and
• a completion step that can be routed for approval before the job is signed off.

Like everything else, work orders move through an enforced status flow and can be scheduled against your team’s capacity.

Service desk

The service desk handles support tickets end to end. A ticket carries a reference, a subject and description, a priority, impact and urgency, a requester and customer, and it is routed to a queue, a team and an assignee. Beyond the basics it supports replies to the requester, macros (canned responses and actions), evidence, fulfilment tasks and a link to a service contract for coverage.

Tickets are governed by SLA policies. For each priority you set first-response and resolution targets, and the module calculates the response-due and resolution-due times, tracks first response and resolution, can pause the clock (for example while waiting on the customer), and flags a breach with escalation when a target is missed. A ticket report gives you the shape of the support workload.

The service desk is configured through its admin area: queues, teams and their members, services, SLA policies, macros and assignment rules that route tickets automatically. A public ticket portal, secured by a rotating portal key and per-ticket tokens, lets customers submit and follow up on tickets without a login.

Service contracts

A service contract is the coverage that sits behind support — a retainer or an entitlement for a customer. It records the covered services, a coverage model, included minutes or included incidents and what has been used against them, a retainer amount and currency, an SLA policy, and an effective period. Contracts are activated and cancelled through their own lifecycle, and where an SLA is missed a service credit can be recorded against the contract. Service reviews summarise how a customer’s service performed over a period, with an optional AI-written narrative.

Billing & rate cards

Billing runs on billable lines. Effort, materials and expenses accrue against a project, work order or ticket as priced lines, each drawing its rate from a resolved source. A line can be edited, tagged or excluded before it is billed. When the work is ready to invoice, an invoice request is raised — routed through approval where required — and the result is a draft invoice in CRM for the customer, which posts to Accounting through the normal invoice flow. Nothing is billed twice: a line records the invoice it went onto.

Rates come from rate cards. A rate card is a versioned, publishable set of rates with a default and per-scope assignments, and the module resolves the right rate for a given piece of work from those assignments. Rate cards are stewarded as shared master data, so pricing stays consistent across the module rather than being re-entered per job.

Attendance

Attendance captures where and when field work happened, feeding the hours back into timesheets. Staff can punch from the field with location captured, register biometric passkeys for secure punching, and enrol physical attendance devices with rotating keys for site check-in. Batches can be brought in by CSV import with a template, preview and commit, and an ingestion endpoint accepts events from registered devices. Consent is captured and can be revoked, and confirmed punches flow through to HR timesheet entries.

Governance, knowledge & directory

Beyond delivery, Operations carries the supporting registers:

• Governance — organisation-wide risk, issue and decision registers plus actions, with a dashboard and approval routing for decisions.
• Knowledge — a knowledge base of articles with versions, a submit-for-publish approval, archiving, linking, ticket suggestions and gap detection.
• Directory — a shared read of staff, employees, contacts, accounts, CRM contracts, products and documents that other Operations screens draw on.

Scheduling

A calendar view schedules work across the team, with a capacity read and a conflict check so a person is not double-booked before an assignment is confirmed.

Access & permissions {#access-and-permissions}

Every Operations action is governed by a capability, and view and manage are separate — projects, tasks, tickets, work orders, intake, billing, service contracts, rate cards, attendance, governance, knowledge, scheduling and settings each have their own view and manage permissions. Capabilities are grouped into roles and roles are assigned to users, so each person sees and does only what their role allows. This is enforced on every request, not just hidden in the interface, and sensitive figures such as cost and margin sit behind their own permission.

How Operations connects

Operations is where the work happens, but it does not stand alone. On the shared platform foundation:

• CRM receives every invoice request as a real invoice draft — by line, milestone, hour or material — so billing the work and getting paid use one connected record.
• Accounting receives the invoices you raise, so revenue lands in the ledger automatically.
• HR receives confirmed attendance punches as timesheet entries, so field hours become recorded time.
• The customer record is the same one used across the platform, so the client on a project, the customer on a ticket and the account on an invoice are one and the same.
• The approval engine governs milestone acceptance, work-order completion, decisions, article publishing and invoice requests through one shared workflow.

That connection is the point: you take the work in, deliver it, bill it once, and the money and the ledger stay in step.