Contoso Field Services: Justifying a Pilot Before a Rollout
Contoso Field Services has 220 employees. Dispatch runs on a shared Excel workbook on a file server; nine coordinators refresh it hourly and email PDFs to 60 field technicians. Last quarter the workbook was overwritten twice, and average time-to-invoice was 11 days. The IT director has a three-year custom .NET portal quote of $340,000. The Power Platform lead counters with a six-week Power Apps plus Power Automate pilot costing roughly $60,000 in premium licenses and internal time. The CFO has released funds for the pilot only, and has told the team she wants evidence before any company-wide commitment. The technicians' phones are mixed Android and iOS, and two of the nine coordinators are contractors who work only during peak season.
1. Which business-value claims can the team defensibly make for the pilot, and which claims should they avoid?
Read the worked answer
Defensible claims are the ones tied to a measurable baseline the team already has: 11-day time-to-invoice, coordinator hours spent refreshing and emailing, and rework caused by the two overwrites. These are process metrics the pilot can move and measure within six weeks.
Claims to avoid are the ones with no baseline and no causal link: "digital transformation," "we will eliminate the .NET project," or fixed savings figures before the pilot runs. Likewise, do not promise that premium licensing replaces coordinator headcount - nine coordinators is not a number the pilot changes.
Because the CFO is funding evidence, not a platform, the value story should be structured as: baseline → measured change on 25 users → cost per transaction at roll-out scale. Any claim that requires the roll-out to already be true is circular and will not survive scrutiny.
2. The pilot succeeds with 25 technicians. What evidence should the team collect to support a roll-out decision, and what would weaken the case?
Read the worked answer
Collect paired before/after data on the same metrics used to justify the pilot: median time-to-invoice, coordinator hours per week, number of re-keying corrections, and technician completion rate. Also record leading indicators of adoption - percentage of jobs captured in the app rather than on paper, and how many technicians abandon the app after week two.
The case weakens if the pilot ran with hand-picked technicians, if a coordinator still manually reconciled data behind the scenes, or if the cost per user at 25 does not scale down at 60. Seasonal contractors matter here: they need access for a few months, which changes the licensing model, so the roll-out cost estimate must show the contractor scenario rather than assuming 60 permanent users.
3. Which Power Platform workload should own which part of the process, and what licensing consequence follows?
Read the worked answer
Power Apps should own field data capture, because technicians need a task-specific mobile interface rather than a spreadsheet. Power Automate should own the dispatch notification and any approval or escalation, because those are event-driven steps with no human screen. Power BI should own the invoice-timeline reporting, because that is aggregate analysis, not data entry.
The licensing consequence is the judgement call: if the app uses only standard connectors (for example, SharePoint or Outlook), the technicians may be covered by a Microsoft 365 license; the moment a premium connector or Dataverse is introduced, every technician needs a Power Apps premium license. At 60 technicians that difference can exceed the pilot's entire budget, so the team should decide the data platform before quoting a roll-out price rather than after.