When a services-heavy post-sales team is small, the state of every implementation lives in a few people's heads. Each engineer knows which customers are at kickoff, which are stuck waiting on an admin and how many hours went into last week's workshop. That works until the book grows. Then the questions leadership asks get harder to answer: Where does every implementation stand right now? Which ones are slipping? How is the team's time actually being spent, and how much of it is billable?
This guide explains how to track implementation milestones and billable effort across a whole book of accounts, not one project at a time. It draws on how Mycroft, a GRC platform whose field engineers guide customers through security framework implementations, replaced hand-maintained spreadsheets with one project per engagement in Quivly Projects.
Why Spreadsheets Break Down Across a Book of Accounts
Most teams start tracking implementations in a spreadsheet, and for a handful of customers it is fine. The trouble is that a spreadsheet only knows what someone typed into it. As the number of accounts grows, three problems show up together.
- Status goes stale. Milestones are updated when someone remembers, so the sheet describes last week rather than today.
- Effort is reconstructed after the fact. Hours get logged at the end of the week from memory, which makes billing disputes and capacity planning guesswork.
- There is no portfolio view. Each tab or row tells you about one customer. Seeing every implementation at once, sorted by risk or due date, means building a report by hand.
Mycroft hit all three. Every customer runs a security framework implementation, and across its book those engagements span 10 to 15 different frameworks, with each customer at a different milestone. Field engineers bill against those engagements, so tracking who was working on what, how far along each framework was and how many hours each engineer was spending all happened manually. In the team's own words it was tedious to maintain and impossible to get a clean view across the book.
Make Each Engagement Its Own Project
The first change is structural. Instead of one master sheet with a row per customer, treat every billable engagement as its own project with an owner, milestones, tasks and a due date. If a customer runs two separate implementations, they get two projects, because the work, the timeline and the hours are different.
This sounds like more overhead, but it is what makes portfolio tracking possible. When every engagement has the same shape, you can roll them up: all projects by owner, all projects at risk, all projects due this month. Mycroft runs every security framework implementation as a separate project, so each one carries its own milestones, progress and effort.
A good project record for an implementation includes:
- The customer, the engagement type and the accountable owner
- A milestone plan with dates, from kickoff through go-live
- Tasks for both your team and the customer, including information requests
- Planned and actual effort per person
- A health or status flag, such as on track, at risk or off track
Define Milestones That Mean Something
Milestones are only useful for tracking if everyone agrees what "done" means. Vague milestones like "configuration" or "training" invite optimistic updates. Concrete milestones tied to an outcome or a sign-off are harder to fudge and easier to compare across accounts.
- Start from a template. Repeatable engagement types should share a template that sets milestones, owners and target days relative to kickoff. Quivly Projects templates set the milestones, owners and dates, and forms collect the files, screenshots and answers the team is waiting on.
- Tie each milestone to evidence. A milestone such as "SSO configured and tested" or "architecture sign-off received" can be verified. "Integration mostly done" cannot.
- Separate customer-owned steps. Many delays come from the customer side, such as a missing admin or a document not yet sent. Track those as customer tasks so the plan shows where the wait actually is.
- Keep the same milestone names across accounts. Consistent names are what let you ask "how many customers are stuck before go-live?" across the book.
If you want a deeper look at milestone design, see our guide to onboarding milestones.
Track Effort Against Billable Hours as the Work Happens
For teams that bill implementation time, effort tracking is not an admin chore. It is revenue, and it is also the clearest evidence you have about where the team's capacity goes. The goal is to capture effort on the project where the work happens, not in a separate timesheet filled in on Friday afternoon.
At Mycroft, each engagement tracks time and effort per field engineer against billable hours, sets milestones and manages progress, replacing the spreadsheets the team used to maintain by hand. In Quivly Projects, health, blockers and planned versus actual effort stay in one place on the project record.
Once effort lives on the project, a few useful views follow naturally:
- Planned versus actual by engagement. Spot projects that are consuming more effort than scoped before the overrun becomes a billing conversation.
- Effort by engineer. See who is overloaded and who has room before assigning the next kickoff.
- Effort by engagement type. Learn which kinds of implementation reliably take longer than planned, and fix the template or the pricing.
Let New Engagements Create Their Own Projects
The weakest moment in any tracking system is setup. If someone has to remember to create the project, pick the template and add the milestones, some engagements will start without a record, and the portfolio view will quietly be incomplete.
Mycroft removed that step. When a customer opts into a compliance framework, Quivly's AI agents automatically spin up a project for that implementation, with the right tasks, milestones and success tracks already in place. As a customer takes on additional frameworks, new projects are created for each one, so every engagement is tracked from day one without a field engineer building it out by hand. As Ryan Torio, Director of GRC Engineering at Mycroft, put it: "Quivly spinning up a project the moment a customer takes on a new framework has transformed how we operate."
The general lesson applies even if your trigger is different. Decide what event starts an engagement, such as a signed order, a new module purchase or a customer selecting a new scope, and make that event create the project automatically from the right template.
Build the Portfolio View Leadership Actually Needs
Leadership rarely wants to open individual projects. They want answers across the book. Before Quivly, Mycroft's leadership was asking for clear milestones, time-to-value metrics and customer engineering performance data, and the team felt pressure to build custom solutions just to fill the gap.
With projects and effort tracked consistently, the portfolio view becomes a filter rather than a report. Useful cuts include:
- All active implementations by status, with at-risk and overdue projects at the top
- Milestone and time-to-value tracking by engagement type
- Accounts and effort by engineer
- Upcoming renewals for customers whose implementation is still open
Mycroft's field engineer performance dashboards now surface ARR and customer count by field engineer, milestone and time-to-value tracking by framework, and upcoming renewals filtered by month, quarter and segment. Those dashboards became the first screen field engineers open each day. For guidance on choosing the right time-to-value metric, read how to measure time to value.
Keep the Record Accurate Without Chasing Updates
Every tracking system decays if updates depend on people remembering. The practical fix is to keep updates close to where work already happens. Requests to customers should go out from the project and replies should land back on it. Tasks raised in calls, emails and chat should become proposed tasks on the project rather than notes in someone's inbox.
In Quivly Projects, tasks, customer replies and approvals stay on the project, and requests go out through Slack, email and the customer portal. Agents turn the conversation into a proposed task, risk or blocker, with the evidence attached, and someone on the team still approves it. That review step matters. It keeps the record trustworthy while removing most of the manual upkeep.
A simple weekly rhythm helps too: review at-risk projects, confirm any milestone that slipped, and check planned versus actual effort on the largest engagements. With the data already on the projects, this takes minutes rather than an afternoon of spreadsheet reconciliation.
Where Quivly Fits
If your post-sales or forward deployed engineering team bills for implementation work and still tracks it by hand, Quivly Projects gives every engagement a shared workspace for your team, your customer and AI agents, with milestones, effort and health on one record. Read the full Mycroft customer story to see how one team made the switch, or explore how Quivly supports forward deployed engineers.
