Industries - Technology & IT Services
You sell delivery capacity. Most firms cannot measure what it costs.
Technology and IT services firms run projects, support desks and recurring contracts side by side, usually across PSA, service management and finance systems that do not reconcile. Time arrives late, change requests get absorbed, and cost-to-serve per client is unknown. We connect CRM, projects, tickets, time capture, recurring billing and reporting so utilisation and margin are read rather than estimated.
At a glance
- Typical profile
- Managed service providers, software and implementation firms, and IT consultancies.
- Most common constraint
- Project and support data separated, and time captured too late to be accurate.
- Where we usually start
- Time capture at the point of work and change request workflow.
Operating model
Lead to renewal.
Eight stages. Margin is decided at scoping and revealed at reporting.
Eight connected stages spanning project and recurring service work on one client record. SLA breaches and scope changes branch to a person, and client profitability returns to scoping and renewal.
- 01
Lead and qualification
CRM · Lead, contract
Inbound enquiry, referral and outbound activity, qualified against the work you actually want rather than the work that arrives.
- 02
Scoping and proposal
CRM / PSA · Statement of work
Estimation, statement of work and commercial model. The point where delivery risk is either priced or inherited.
- 03
Project delivery
PSA · Project, milestone
Milestones, resourcing, change requests and dependencies, tracked against the estimate that won the work.
- 04
Support and service desk
ITSM · Ticket, SLA
Tickets, SLAs and recurring issues, which for many firms carry the relationship far longer than the project did.
- 05
Time, cost and utilisation
PSA / ITSM · Time entry
Effort recorded against project, ticket, contract or internal work - the data everything commercial depends on.
- 06
Billing
Finance · Invoice, recurring charge
Fixed fee, time and materials, retainer and subscription, frequently all at once and rarely automated together.
- 07
Renewal and expansion
CRM · Renewal
Contract renewals and additional work, which are cheaper than new business and usually least systematised.
- 08
Reporting
Leadership · Client profitability
Project margin, recurring revenue, utilisation and support cost by client, ideally from one dataset.
SLA or scope exception
A breach risk, out-of-contract request or unbudgeted work raises a decision for a delivery lead, so it is either approved, billed or declined instead of quietly consuming the contract margin.
Time recorded against project, ticket and contract returns to scoping and renewal pricing, so recurring agreements reflect the support load each client actually generates.
Constraints
Five constraints that cap services margin.
01Project and support running as separate businesses
When delivery and service desk data never meet, nobody can see the total cost of serving a client, and unprofitable accounts persist.
02Time capture that is late and approximate
Timesheets completed on Friday from memory make utilisation, project margin and billing all unreliable at once.
03Scope changes absorbed silently
Without a change request workflow, additional work becomes goodwill by default and margin erodes without anyone deciding to allow it.
04Recurring revenue managed in spreadsheets
Contracts, renewal dates, price increases and included hours held outside a system leak revenue and create awkward client conversations.
05Estimates never compared to actuals
Firms that do not close the loop between quoted and delivered effort repeat the same underpricing on every similar project.
Automation
Automation that makes margin visible.
| Opportunity | What changes |
|---|---|
| Lead to proposal workflow | Qualification, estimation and proposal generation as a repeatable process, so quality does not vary with whoever is available. |
| Project and ticket linkage | Support tickets connected to the client, contract and project, giving a real cost-to-serve figure per account. |
| Time capture at the point of work | Effort recorded against tickets and tasks as work happens rather than reconstructed weekly. |
| Change request workflow | Scope changes captured, approved and priced before delivery, converting absorbed work into billed work or a conscious decision. |
| Recurring billing automation | Retainers, subscriptions and included-hours tracking billed automatically with visibility of consumption against entitlement. |
| Margin and utilisation reporting | Project margin, support cost and utilisation read from the same operational data rather than reconciled monthly. |
Architecture
One client record across delivery and support.
Delivery systems should own
Work and effort
- Projects, tasks and milestones
- Support tickets and SLAs
- Time capture and resourcing
- Change requests and approvals
- Delivery documentation
CRM and finance should own
Client and commercials
- Pipeline, proposals and win rates
- Contracts, renewals and entitlements
- Client relationship and account history
- Invoicing across fixed, T&M and recurring
- Revenue, margin and forecast reporting
Where we start
Projects, tickets, time and recurring revenue rarely reconcile without manual assembly.
We start with the operating model, then choose platforms against it. If the model does not need a capability, we do not licence it.
Practical AI
Where AI fits a services firm.
Drafting, triage and analysis - all reviewed before anything reaches a client.
Drafting proposals from prior work
Assembling first-draft scope and pricing structure from comparable past projects, which a person then verifies against the actual requirement.
Ticket triage and routing
Classifying incoming requests by type, urgency and likely owner, with response drafting for common issues under human review.
Summarising delivery status
Turning task, ticket and time data into a client-ready status summary rather than an hour of manual assembly each week.
Estimate-to-actual analysis
Identifying work types that consistently exceed estimate, so pricing models get corrected rather than defended.
Platform roles
Which system should own which job.
Zoho where CRM, projects and service desk should share a spine
Pipeline, project delivery and support in one connected suite suits firms that need cost-to-serve visibility without integrating three vendors.
Zoho Desk where support is the relationship
Managed service and support-led businesses often gain most from structured ticketing, SLA visibility and entitlement tracking.
Odoo where projects, timesheets and finance belong together
Firms wanting project accounting, timesheets and invoicing inside one system rather than integrated across two tend to fit here.
Integration where specialist tools must remain
Monitoring, RMM and development tooling generally stay. The task is connecting them to the commercial systems that need their data.
Implementation
Four things that decide the outcome.
01Technical teams resist administrative overhead
If time and ticket capture is slower than the work it records, it will not happen. Design capture into the tools people already use.
02Define the client record boundary early
CRM, delivery and support all want to own the client. Decide once, integrate one way, and avoid three divergent contact lists.
03Migrate contracts and entitlements carefully
Recurring revenue data is the highest-risk migration in this sector. Errors here appear directly on invoices.
04Prove it on one service line first
A single delivery stream running end to end reveals the design problems faster than a whole-firm rollout.
Technology services systems questions we are asked most
- Do we need PSA, service management, or both?
- Firms that are mostly project-based generally get further with PSA and CRM connected to finance. Firms carrying managed contracts and ticket volume need service management alongside it, with a clear rule about which system owns the client record and the billable time. We work through the split before recommending tooling.
- Should projects and support live in the same system?
- They should at least share the client, contract and time data. Whether they share one interface depends on your mix: project-led firms usually anchor on delivery, support-led firms on service desk. What is not viable is having neither able to see the other's cost.
- How do we get accurate project margin?
- By capturing effort at the point of work, linking support and rework to the originating project, and running estimate-versus-actual review as routine. Margin problems in this sector are almost always measurement problems first.
- What is the best way to handle retainers and included hours?
- Track entitlement consumption against the contract in the same system that records the work, with visibility for both your team and the client. Managing this in spreadsheets is where most recurring revenue leaks originate.
- We already use several specialist tools. Do we replace them?
- Usually not. Monitoring, RMM and development tools are rarely the problem. The gap is generally that commercial systems cannot see their data, which is an integration and architecture question.
- Where should a growing firm start?
- Time capture and change request workflow. Together they make margin visible and stop unpriced scope, which is typically the largest single leak in a services business.
Where to go next
Compare last quarter's estimates with what delivery actually cost.
If that comparison is difficult to produce, the measurement gap is usually worth more than the pricing conversation.