My FileMaker / Newton MessagePad Story

Apple is, and always has been, a religion. And in the early ’90s, I got to be part of the congregation. After six years of selling Apple products, I joined the Austin campus as a technical support agent. At the orientation meeting, we were informed that our team would be supporting a brand-new product called the Newton MessagePad.

Supporting the Newton MessagePad came with its fair share of challenges. As a brand-new product, documentation was sparse, and troubleshooting required a mix of technical intuition and teamwork. We quickly realized that handwriting recognition, one of its flagship features, had a steep learning curve both for users and support agents.

In order to support incoming support calls, we were required to use a technical support knowledgebase called Tres Cool. The irony? It wasn’t cool at all. The system was slow, clunky, and outdated. Searching for information often led us down dead ends, and the approval process for adding new knowledge was so drawn out that new insights became outdated before they were published.

Since Tres Cool was ineffective, our team resorted to email threads and in-person meetings to share insights. While this was more immediate, it had its own problems—emails quickly got buried in inboxes, and searching for a specific solution meant digging through long chains of messages. As Newton support questions became more varied and complex, the ad-hoc nature of our knowledge sharing made it clear that we needed a structured, searchable repository that could evolve with our needs.

BUILDING A KNOWLEDGE BASE TOOL

So, when I needed a better technical knowledge repository, I naturally tried to build one in FileMaker.

Before joining Apple, I spent four years selling Macintosh computers through small mail-order companies as part of the Apple Value Added Reseller program. The first company I worked for didn’t have an inventory system that connected to the sales process. In order to better tell customers what we had in stock, I built an inventory module to our existing FileMaker invoicing system. Before long, I had added other enhancements such as a returns module, a credit authorization module, and a lead tracking module.

Initially, my FileMaker repository was a personal project, just a way for me to quickly retrieve useful support information. I invested a considerable amount of time copying / pasting support information from various sources, cleaning up the content, organizing content into categories and even built in a small call logging feature that helped fill gaps in our official call logging solution.

With the help of the tool, I quickly began to dominate the daily reports for support calls. My cube neighbor saw what I was doing, asked for a copy of the tool and he also began to level up on the daily support calls. I didn’t have any issues with sharing the tool (most FileMaker developers love to share) and it didn’t take long before half the team was using "the tool" and the other half was just learning about it.

What started as a solo project soon became a team-wide effort. Agents were eager to contribute their own insights, sending me updates, troubleshooting steps, and common fixes that weren’t documented elsewhere. This sense of ownership helped drive engagement, people weren’t just using the tool; they were invested in making it better. Each new release felt like a team milestone, reinforcing our bond and fostering a collaborative, problem-solving culture.

As more team members adopted the tool, we saw tangible improvements in our support efficiency. Call resolution times dropped, and agents were able to provide more accurate answers with confidence. Instead of fumbling through outdated knowledge bases or lengthy email threads, we had a fast, searchable resource that evolved in real time.

THEN THINGS GOT A LITTLE DRAMATIC

Before this experience, I had assumed that results spoke for themselves, if something improved productivity and morale, it would be embraced. But I quickly learned that corporate environments often operate on unspoken rules and territorial concerns. The tools support group, feeling bypassed, had flexed its authority, not because my tool didn’t work, but because they hadn’t sanctioned it. This was my first real exposure to the politics of workplace innovation, where success doesn’t always equate to acceptance.

The Newton Support Team manager pulled me into a room and told me that I was being placed on probation. That in creating and sharing the tool, I had violated a policy (unwritten? at the time) about creating support tools without the expressed permission of the tools support group. I was ordered to delete all copies of the tool and promise to never build an internal tool like it again. Of course, I agreed with all those terms and was genuinely regretful that my actions were being seen in this unpleasant light.

When “word” spread that I had been placed on probation and ordered to delete the tool, the team was shocked. Many of my colleagues had come to rely on it for their daily work, and they saw the decision as both unfair and counterproductive. Some team members quietly backed up copies of the tool, determined to keep using it despite the official crackdown. Fortunately, the controversy led to productive discussions. Eventually, the official Support Tools Team released an improved tool that expanded on the features we had built. The experience reinforced an important lesson: sometimes, challenging a system is the catalyst it needs to evolve.

AN UNEXPECTED CAREER PIVOT

Then something strange started to happen, my ability to use FileMaker to build unique solutions started to gain traction. I was increasingly pulled off phone support duties to develop specialized FileMaker tools for the call center. ?I was also asked to support some of the existing FileMaker solutions that were built for the Administration group to handle building employee management, equipment inventory and much more.

One day, I was approached with a proposal to formalize my role as an internal FileMaker developer. I was asked to draft the job description, apply, and interview. I held that role for another 5 years and eventually left to spin up my own independent FileMaker design company. ?My transition from a support agent to a FileMaker developer wasn’t just a career pivot; it was proof that solving problems effectively can create new job opportunities, even in unexpected ways.