Precisely: Operating Analytics

As a services leader, I have ninety AI ideas from my own people and no way to tell which two are worth funding this year. I do not need more ideas. I need a defensible way to rank the ones I have.

I joined Precisely's global services organization and inherited a spreadsheet. It held more than ninety proposed AI use cases, submitted by people across the professional services organization who knew their own workflows well and had real ideas about where AI would help.

No two proposals were comparable. They were written at different altitudes, justified in different units, and sized by whoever happened to submit them. Some claimed hours saved; some claimed revenue; most claimed neither. There was no mechanism for deciding which ones deserved a budget, so none of them were moving.

I built a weighted scoring framework, so that ninety proposals written ninety different ways could be scored on one scale.

Then I automated it. Intake and scoring run through a Power Automate workflow, so a submission is captured and scored consistently rather than depending on who reviewed it. Human-in-the-loop review gates sit at the points where judgment genuinely matters, because a scoring model that no one can override is a model people learn to game rather than trust.

The framework produced five highest-value cases, which went onto the enterprise AI transformation roadmap with an estimated $225,540 P&L impact over the following fiscal year. One of those five became my build.

As a business unit leader, I need to know where my pipeline stands now, not where it stood at the end of last month. And I should not have to ask FP&A to find out.

The initiative I picked up was the Monthly Operating Report. Producing it took FP&A three to four working days of manual assembly, every month. That cost was visible. The second cost was invisible. The report was monthly, so it gave leaders a snapshot rather than a picture. Between publications, anyone who needed a number either waited or guessed.

I started gathering requirements on day one and met with executive leadership inside the first week. On a ten-week engagement, discovering an executive constraint in week six is indistinguishable from missing it, so I did not wait. I aligned stakeholders across data engineering, FP&A, operations, professional services, and the executive leadership team, which is five functions with genuinely different definitions of what the report was for.

The requirements resolved into three categories:

• Take the manual labour out of producing the report. The three-to-four day assembly cost was the loudest complaint and the easiest to measure.
• Add AI-enabled decision support through conversational analytics. Leaders did not want a dashboard with every possible cut of the data; they wanted to ask a question and get an answer.
• Present it with executive polish and keep it always available. If the data is live but nobody trusts how it looks in a board setting, it does not get used, and people go back to asking FP&A.

I prioritized the resulting user stories with MoSCoW, which mattered more than usual here because the timeline was truncated and the stakeholder set was wide. Explicitly labelling what would not ship in the first release was what kept five functions aligned on one scope.

Midway through the engagement, feedback reached me through my manager, which is the worst way it can arrive. One of the senior leaders had come away from our requirements sessions feeling I didn't listen. On a project whose first deliverable was listening, that stung.

I went back through the call transcript expecting to disagree, and found the opposite. I had heard every requirement. All of them were captured, accurately. But each time they raised a business problem, I had answered in solution space: architecture, data models, integration constraints, worked out loud in real time with a non-technical executive. What felt to me like engagement read to them as being talked past.

I addressed it with them directly, and changed how I ran the sessions: their problem restated in their terms before anything else, and the solutioning saved for a separate conversation with the right audience in the room. We worked closely for the remainder of the engagement.

By the end, that senior leader was the most engaged stakeholder on the project. They contributed more user stories than any other senior leader. The lesson outlived the engagement: discovery conversations and design conversations are different meetings, and I no longer let one turn into the other.

With a compressed timeline, I chose to prove the product before building the platform. I built the MVP as a Claude artifact in four weeks and put it into the next Monthly Operating Report, where business unit leaders used it to pull live insights during the meeting itself.

With the concept validated, I wrote the functional spec and PRD for the full solution and presented to the Global Services technical review board weekly, which kept the architecture honest and the technical stakeholders bought in rather than briefed at the end.

Partway through, I found that the data team was independently building a sales agent. Rather than let two systems define the same metrics differently, I coordinated with a director in that organization to build RevOps metrics specific to professional services into their semantic layer, and contributed a new filtered field to their schema capturing how professional services separates its product lines, a taxonomy that differs from the rest of the organization and would otherwise have produced two sets of numbers that disagreed without anyone noticing. Two teams were about to encode the same business logic in two places. Nobody notices that kind of duplication until the numbers disagree in front of an executive, and finding it was worth more than anything I built that week.

I built the full-stack application containerized within Snowpark Container Services. The technical reason was proximity. The source revenue data already lived in Snowflake, so the integration was direct. Access was gated behind Snowflake RBAC rather than reimplemented in the application.

The organizational reason mattered more. Running inside Snowpark put cloud governance with Precisely’s data team, who own that platform and staff it accordingly. Global Services, where this tool lives and where its users are, is a largely non-technical organization. Hosting it anywhere else would have handed long-term maintenance and technical debt to a team with no capacity to carry it.

The full topology is documented in the blueprint linked below, including two decisions this summary leaves out: how the client loads data in groups and falls back to flagged stale figures rather than an empty screen during a warehouse outage, and how two long-lived branches map to two accounts so nothing reaches production without first running in non-production.

• Operating Analytics live with 30+ senior leaders across the global services organization, delivering live pipeline insight and conversational analytics in place of a monthly snapshot
• Three to four working days per month of FP&A labour recovered, redirected from assembling the report to acting on it
• $225,540 projected P&L impact across the five roadmap cases the scoring framework surfaced, with the top-ranked one now shipped
• 32% increase in AI enablement across the global services team, measured by token usage and account sign-ons

The adoption number came from work alongside the build. I led three AI training sessions to 70+ attendees across the organization, covering Claude foundations, skills, artifacts, and scheduled tasks. Building a tool that assumes AI fluency in an organization that does not yet have it is a good way to ship something nobody opens twice.

The engagement ran ten weeks, with the platform delivered zero-to-one in eight. I was brought back with a title change from AI Tech Analyst to AI Solutions Associate to keep extending the platform and running stakeholder training through the academic year.