From support problem to usable AI workflow.

This case study describes workplace work without naming the organization or sharing internal materials. The examples are anonymized and the sample customer scenarios are fictional. Outcomes are based on my observations and coworker feedback; I did not record formal accuracy rates, adoption percentages, or timed before-and-after productivity measurements.

The method at a glance

1. Step 1

   Start with the work

2. Step 2

   Ground it in existing sources

3. Step 3

   Test the ugly cases

4. Step 4

   Keep human review

5. Step 5

   Teach the check

6. Step 6

   Maintain the knowledge

1. Start with work people already have to do.

The starting point was not “where can I put AI?” It was a pair of familiar support tasks where people sometimes had to stop and figure out which existing option fit the situation.

One task was choosing the right response template for a customer email. The other was choosing the right ServiceNow category. Both already had source material. The opportunity was to make that material easier to use without taking the decision away from the employee.

2. Ground the agent in the material the workflow already depends on.

For the response workflow, I configured a Copilot agent around response documents stored in SharePoint. An employee could paste a customer email into the agent. It returned the relevant template name and full text, or a suggested response with an explanation when no single template fully fit.

The employee still reviewed and edited the result before sending anything. A straightforward fictional request, such as a delayed delivery, could map cleanly to the relevant response. An email combining a delivery problem and an account problem needed more judgment because one template might not answer both issues.

For the category workflow, a second Copilot agent used an Excel file in SharePoint containing the available ServiceNow categories. The employee pasted the email into the agent, received a category suggestion, and manually selected the category in ServiceNow.

The agent did not update ServiceNow, send responses, or make the final decision on the employee’s behalf. Its job was to make the next decision easier to reach.

3. Test the cases that make the workflow uncomfortable.

When an answer missed the issue or included unsupported details, I revised the instructions and tried the same examples again. I removed redundant wording, added specific “do not” constraints, and compared whether the revised answer addressed the complaint more directly without inventing facts.

Poor grammar and emails containing several different issues were harder cases. Those were useful precisely because they exposed where a clean demo could hide a weak instruction set. Many responses needed no changes in my use; others needed manual correction.

This was iterative workflow testing, not a formal benchmark. I did not build a labeled evaluation set or record an accuracy percentage for the workplace agents.

4. Put adoption inside the implementation, not after it.

I showed coworkers how to find the agents, explained what each one did, walked through examples, and let people try the workflow themselves. I also taught them to consult the relevant knowledge-base articles or standard operating procedures when they were unsure about a suggestion.

That mattered because adoption was not just “here is a new AI tool.” The useful habit was: get the suggestion, understand why it might fit, and know what source to check when it does not.

A few coworkers reported that the agents saved time and effort and continued using them regularly. That is qualitative evidence from the people using the workflow, not a measured team-wide productivity result.

5. Give people instructions they can actually follow.

I also developed two AI-assisted instructional PDFs for employees. I used AI to research learning resources and help draft the material, while I chose the audience and approach, directed the language and visual style, reviewed the output, and edited it for clarity.

After manager approval, I distributed the guides to the team. Colleagues said the material answered questions they had. As with the agents, that feedback was useful but informal rather than a controlled measurement of training effectiveness.

6. Maintain the knowledge after the first version works.

When new response templates became available, I added them to SharePoint so the response agent could use the current material. The source documents were accessible to the coworkers using the workflow.

That maintenance work is part of implementation. A useful agent can become a bad one if its knowledge quietly falls behind the process it is supposed to support.

7. Know what still needs to be measured.

If I were formalizing the next implementation, I would capture a baseline before changing the workflow and decide on a small set of measures up front. Depending on the task, that could include how often people use the tool, how often they edit or reject its suggestion, time spent on the task, repeated error types, unsupported details, and whether people keep using it after the initial demonstration.

The point is not to manufacture a giant dashboard. It is to be able to answer a basic question with evidence: did the workflow actually get better?

What I take into the next implementation.

Start with a task people already need to do. Give the system the sources that task already depends on. Test the ugly examples, not just the demo-friendly ones. Keep the person in control. Teach the check. Maintain the source material. Decide how you will know whether the change helped.

My public projects give me another place to push on those same questions: TinyDesk for workflow design, human review, and a small measured evaluation; Cricket Mode for repeatable agent behavior across tools; and TinyTalk for memory reliability and source status.

TinyDesk’s twelve-ticket results belong to that fictional demo and are separate from the workplace observations described here.