A Better Nimble AMS Consulting Experience

Do not index

Learnings

You shouldn't need a second meeting to find out what the first meeting was supposed to accomplish.

If you're paying for Nimble AMS consulting, you should be able to ask a straightforward question about your system and get a clear answer. What does this process do? Why was it designed that way? What happens in the exception case? Where is that documented?

Those aren't unreasonable requests. They're the basics.

At Seawalker Tech, I've built my consulting practice around a simple idea: the person discussing your requirements should understand the solution well enough to design it, build it, test it, and explain it afterward.

One architect. One continuous conversation.

I'm Mark Marchand, founder of Seawalker Tech and a Nimble AMS consultant and solution architect. I've worked with Nimble AMS since 2014, including several years at NimbleUser (now Momentive Software) before starting my own consultancy.

When you work with Seawalker, you work directly with me. I handle business analysis, solution architecture, and implementation. Your requirements don't get passed from a discovery team to a design team to a developer who is unavailable for the conversation.

I 100% get that there is a place for larger delivery teams. But adding people isn't the same thing as adding clarity. Every handoff creates an opportunity for an important detail to become a footnote, an assumption, or something nobody quite owns.

My model keeps that ownership intact. The person who asks why your staff needs a particular workflow is the person who makes sure the finished solution supports it.

Design first. Estimate clearly. Then build.

A demo of something that mostly works is not a substitute for an agreed design.

Before I start building, we work through what your organization actually needs. That includes the intended behavior, the important exceptions, the boundaries of the work, and what successful delivery looks like.

I document the requirements and proposed solution in structured stories. We review the specification and a clear estimate before you approve the build. You can see what you're buying, what is outside the scope, and which assumptions the estimate depends on.

That doesn't mean requirements can never change. It means changes are visible decisions rather than surprises buried in an invoice or discovered during launch.

You shouldn't have to approve a vague promise and hope the details turn out well.

Documentation should answer questions, not generate them.

A useful implementation record explains more than which buttons to click. It captures what the solution is intended to do, why it works that way, and where its limits are.

For example, if an automation exchanges information with another system, your team should be able to determine what starts the process, what a successful result looks like, and what staff should do when something needs attention. The principle applies just as much to membership, events, accounting, and Community Hub.

My documentation connects the business requirement to the agreed behavior and the delivered solution. Acceptance criteria make the expected result explicit. Seawalker’s manifest documents precisely what was added, updated, and/or deleted to make the new feature a reality. Supporting instructions explain how your team uses the result.

These aren't three unrelated documents written by people who met at the handoff. They're different views of the same work, built by a single artisan.

Testing is part of delivery, not an afterthought.

I build against the agreed specification, test the solution, and work through client validation before calling the job complete.

The important question isn't only whether a process works once. It's whether the relevant scenarios behave as intended, including the less convenient ones. What happens when required information is missing? What should happen when a user isn't eligible? How does the process behave when the expected next step isn't available?

The answers depend on the project. The discipline shouldn't.

No consultant can honestly promise a bug-free system forever. What I can offer is direct accountability, a documented basis for testing, and continuity when a question or issue needs investigation.

Seawalker TV: State-of-the-art recorded demos your team will actually watch.

Documentation doesn't have to mean handing over a wall of text and wishing everyone luck.

I provide detailed, recorded demonstrations available on demand with modern capabilities your team expects these days, including download capability, transcripts, chapters, variable playback speed, and 4K quality so your team can revisit the relevant parts without scrubbing through an entire video. You can watch the workflow, read the explanation, or jump straight to the part you need.

Seawalker TV offers recorded demos of your complex Nimble AMS customizations with modern video playback features as well as state-of-the-art AI capabilities including SOP generation derived from the video’s contents.

But I go even further than that; you can ask Seawalker TV to generate a document with the detailed clickpaths that were demoed. Combine that with a PDF of the story documentation, and you can pass both to your trusted LLM to create an SOP for your team!

At Seawalker, I am not anti-AI or slop-AI; I am all about using AI tastefully and correctly to accelerate our partnership and your team without sacrificing quality.

All of this matters when someone misses a session, a new staff member joins, or an administrator needs to refresh their memory months later.

And because I'm demonstrating the solution I designed and built, I can explain both how to use it and the reasoning behind it. The recording is a reference, not a substitute for being able to ask me a question.

Living documentation, not a launch-day souvenir.

A guide that describes last year's configuration isn't a reliable guide to this year's system.

I maintain documentation as the solutions I deliver evolve. When we change behavior, the documentation needs to reflect that change. Otherwise, we're creating a second version of reality for your staff to reconcile.

Clear written specifications, current instructions, and searchable transcripts also make the material useful with modern AI tools. If your organization uses an approved LLM, I can help provide the relevant documentation so it can summarize a workflow or help someone locate an explanation.

That doesn't mean uploading your entire system history to a public chatbot. Access, confidentiality, and the choice of tool still matter. The value starts with having accurate source material worth asking questions about.

Choose a consulting model, not just a list of credentials.

If you're looking for a Nimble AMS consultant, ask how the engagement actually works:

Will I speak directly with the person designing and building the solution, and will they be on follow-up calls if we have questions or encounter bugs?

Will the intended behavior and scope be documented before I approve the build?

Will I receive a clear estimate and know how changes are handled?

How will the solution be tested and validated?

Will I receive usable documentation and recorded demonstrations?

Who owns the answer when I ask why something works the way it does?

Maybe a large team sounds good on paper. But in those engagements, chances are no single person knows your Nimble org inside and out.

If you prefer a single Nimble AMS expert who is directly accountable, on every single call with you, and is with you from discovery to design through delivery, Seawalker Tech offers that.

Fewer handoffs. Clearer decisions. Up-to-date documentation you’ll actually read (or ask your agent to). And a direct conversation with the person who built your solutions.

If that sounds like a better way to get more out of your organizations’s invesment in Nimble AMS, let's talk.

A Better Nimble AMS Consulting Experience Starts With Fewer Handoffs