How to Go from “We Need to Track This” to a Working Application — Without a Development Project

Starting with a business problem, not a technical specification

We started with a deliberately simple scenario: “We need to track training requests. We need name and email address, with a three-step workflow.”

That’s it. No requirements document. No data model. No workflow diagram.

We fed this into Servicely’s Product Design Reviewer — an AI assistant purpose-built for turning business problems into platform configuration. It asked a handful of clarification questions, the same kind of questions a good business analyst would ask: What should the workflow stages be? What happens at each step? What data do you need to capture?

Once confirmed, it generated three things automatically: the functional requirements (what the application needs to do), the implementation plan (what needs to be built in the platform — tables, fields, workflow), and then it built the actual application. Table created. Fields configured. Workflow assembled. All from a single conversation thread.

The part that matters most: you can trace everything back

Speed is useful, but it’s not the main benefit here. The main benefit is that every configuration decision is documented and traceable.

The Product Design Doc stays in the system as a living record. The original business requirement, the functional specification, the implementation details, and the change log are all linked. Six months from now, when someone asks “why does this workflow have three stages instead of two?” — the answer is in the doc, along with the conversation that led to the decision.

This solves a problem that every long-tenured ITSM team knows well: the person who built it left, nobody knows why it works this way, and nobody wants to touch it in case something breaks. With AI-driven configuration documented through Product Design Docs, the context is preserved alongside the configuration.

You can even ask SoFi to compare the implementation against the original spec — did what we build match what we designed? That kind of validation usually requires a formal QA review. Here, it’s a question.

What about more complex requests?

The training request example was deliberately simple for a live demo. But the same approach works for more involved processes.

In the webinar, we also demonstrated a complete email resource request workflow — where an employee could request an email alias, distribution list, or shared mailbox through a conversational self-service interface. The AI understood the request type, validated the inputs, provisioned the resource on Exchange, updated the work and client journals, and closed the ticket. End to end, no human involvement required.

The key is that both modes exist on the same platform. Some processes warrant full automation. Others need a human to review and approve before execution. You decide which is which, and you can change the boundary as your confidence in the AI grows.

During the request fulfilment demo, the agent acted as what we call a “human in the loop” — reviewing the AI’s suggested fulfilment plan, confirming the task assignments, and giving the go-ahead. The AI did the analysis and the heavy lifting. The human made the decisions. That’s a much better use of your team’s time than manually creating subtasks and copying data between fields.

A practical way to start

If you’re looking at this and thinking “that sounds great but we have hundreds of processes to digitise,” the good news is you don’t need to do them all at once. The Product Design Doc approach works for one process at a time.

Pick the process that’s causing the most pain — the one that’s stuck in a spreadsheet, that generates the most complaints, that your team spends the most time on manually. Describe it in plain language. Let AI generate the requirements and the implementation plan. Review it. Deploy it. Then move to the next one.

Each process you bring onto the platform makes the next one easier, because the AI learns from the patterns, the data model, and the existing configuration. It’s incremental, low-risk, and immediately valuable.

‍