Systems Integration
Choosing the tool, building it out, and getting your team to actually use it.
When The Tools Stop Keeping Up
Most businesses don't pick a system. They accumulate one. A scheduling tool somebody signed up for, a spreadsheet that became load-bearing, a CRM two people use and four people don't, and a group text where the real decisions happen.
Then you try to add someone new, or pull a report, or find out what was agreed three months ago, and the whole thing shows its seams.
The usual response is to buy something better. But a new tool only fixes this if someone has decided how the work should flow through it first, and that's the part nobody has time for.
The Tool is the Easy Part
Choosing software is a few weeks of demos. Getting a team to actually work inside it is the real project, and it's where most of these fail.
So I start with how the work moves now. Who touches what, where things get handed off, where they stall. Then we design how it should work, and only then do we pick the tool that fits it. Not the other way around.
From there I build it out, working directly with the vendor or their implementation team, to your specifications rather than their defaults. Then I train your people, sit with them through the first stretch, and fix what's awkward before they quietly go back to the spreadsheet.
To be clear about what I'm not: I'm not a developer and I'm not reselling anyone's software. I don't have a preferred platform I'm steering you toward. I care whether the thing works six months from now.
What this Usually Includes
Mapping how work currently moves through the business
Defining the workflow before choosing the tool
Evaluating platforms against how you actually work
Working with the vendor or implementation team on the build
Configuring to your specifications, not the default setup
Migrating existing data and records
Training the team and writing it down
Staying on through the first weeks and fixing what's awkward
Why me
I spent three and a half years at a marketing and PR agency and finished as Director of Traffic and Operations. Traffic is the job of knowing where every project in the building stands and what moves next, which means the system the whole agency ran on was mine to run.
It was also mine to choose. I evaluated the platforms we committed to agency-wide and built the processes for using them, because everyone was using the same tools in their own way, which held up fine until it didn't, usually three months later when nobody could reconstruct what happened. I built the onboarding system we used for new hires and wrote the SOPs that got people working the same way instead of six different ways.
Most of the job, though, was the unglamorous part: getting a room full of busy people to change how they worked. That's the part I'd want you to hire me for. Choosing the software is the easy half.
What Comes Next
Everything Else That isn’t Written Down
This project documents the system we build. Most businesses have the same gap everywhere else: the process that lives in one person's head, the thing nobody can cover for. That's its own project.
Who Owns What
Mapping the workflow usually turns up the bigger question: who's actually responsible for each step. Worth answering on paper.
Outgrown your setup?
Tell me what you're using now and where it's breaking down. We'll figure out whether you need a new tool or just a better way of using the one you have.