Salesforce work, done by the person you talked to
Six service areas that cover the whole life of an org — the steady administration, the cleanup nobody scheduled, and the builds that move the business forward. Engage on any one of them.
Day-to-day administration
The requests that pile up in an inbox because nobody owns them: a new hire needs access, a manager wants a report, a validation rule is blocking the sales team on a Friday afternoon.
We take that queue. Not as a ticket-shuffling helpdesk, but as a senior admin who will occasionally come back and say this request will cause a problem in six months, here is what I’d do instead. That judgment is the difference between an org that stays clean and one that accumulates another layer of debt every quarter.
Ongoing support works as a monthly engagement with an agreed number of hours. Unused hours roll once. If a month is quiet, you’re not paying for someone to look busy.
Included in ongoing support
- User provisioning, profiles, permission sets and role hierarchy
- Page layouts, Lightning record pages, record types
- Validation rules, formula fields, picklist governance
- Reports, dashboards and shared list views
- Data quality: deduplication, bulk updates, imports
- Sandbox refreshes and change set or deployment support
- Salesforce seasonal release review and regression checks
- A monthly written summary of what changed and why
What the assessment produces
- A complete inventory of flows, workflow rules, processes, triggers and validation rules
- Which automations fire on the same object, in what order, and where they conflict
- Fields and objects with no data, no references and no reason to exist
- License and feature usage against what you’re paying for
- Integration points, including the ones nobody documented
- A risk-ranked remediation roadmap with effort estimates
You keep the document whether or not you hire us to act on it.
Determine technical debt
Before you can fix an org, someone has to be able to describe it. Most orgs over three years old have nobody who can.
The assessment is a read-only pass through your Salesforce instance. We catalogue what exists, trace what depends on what, and identify the specific things costing you time — the four automations racing each other on Opportunity save, the 200 custom fields with no data in them, the integration that silently stopped syncing in March.
What you get back is a plain-language document: here is what you have, here is what it’s costing, here is the order to fix it in, and here’s roughly what each piece takes. Priced as a fixed-scope engagement so there’s no open meter.
Agentforce builds
An agent is a new employee with perfect recall and no judgment. Everything depends on what you let it read and what you let it do.
We start by asking whether an agent is the right answer at all. Some of what gets pitched as an AI use case is a flow with a screen on it, and it costs a fraction as much to build. When an agent genuinely is the right call, the work is mostly in the boring parts: choosing grounding sources deliberately, defining actions with real permission boundaries, and testing against cases that actually happened.
We won’t ship an agent into a customer-facing channel until it’s been run against a body of real historical cases and you’ve seen where it got things wrong.
Feasibility and use case
Which of your processes have enough volume, clear enough rules, and good enough data to justify an agent — and which don’t.
Topics, actions and grounding
Designing what the agent handles, what it’s allowed to do about it, and precisely which records and knowledge it reads from.
Guardrails and escalation
Boundaries on scope and permissions, plus a working handoff to a human that fires before a customer gets frustrated.
Test, launch, tune
Evaluation against real historical cases, a staged rollout, and a tuning pass once it’s seen live traffic.
Typical builds
- Record-triggered flows replacing legacy workflow rules and Process Builder
- Screen flows that guide reps through a process instead of relying on training
- Custom objects and junction objects with a relationship model that reports cleanly
- Multi-step approval processes with real escalation paths
- Scheduled flows for recurring data operations
- Fault paths and error handling, so failures surface instead of vanishing
Custom flows & objects
Declarative wherever it can be. Code only where it has to be. Documented either way.
The fastest way to create tomorrow’s technical debt is to build today’s request exactly as it was asked for. We start from the outcome — what does the business actually need to happen — and then choose the simplest mechanism that gets there and stays maintainable by your team after we’re gone.
Every flow we build follows one naming convention, has a description that says what it does, and includes fault handling. That sounds like a small thing. It’s the entire difference between an org someone can pick up and one that has to be reverse-engineered.
Connect external systems to Salesforce
Your ERP knows what shipped. Your billing system knows what was paid. If Salesforce doesn’t, your reps are guessing and your reports are fiction.
We map out what data needs to move, in which direction, how often, and what happens when it fails — before anything gets built. That mapping document is the deliverable people skip, and it’s the one that determines whether the integration is maintainable two years from now.
We work with whatever you already have where that’s sensible: middleware you’re paying for, native connectors, Salesforce Connect for data that shouldn’t be copied at all. Building something custom is the answer when it’s actually the answer, not by default.
What we handle
- Integration discovery: systems, objects, fields, direction, frequency
- Field-level mapping and transformation rules, written down
- REST and SOAP API connections, platform events
- Middleware configuration and connector setup
- External objects via Salesforce Connect for read-only data
- Error handling, retry logic and failure alerting
- Replacing brittle point-to-point scripts nobody maintains
Projects we take on
- Merging orgs after an acquisition
- Standing up a new cloud — Service, Experience, Revenue
- Architecture review before a large internal build
- Second opinion on a vendor proposal or SOW
- AppExchange evaluation and selection
- Compliance and audit preparation
- Mentoring an internal admin into the role properly
Special project consulting
The work that doesn’t have a tidy category — usually the work with the most riding on it.
Sometimes what a team needs isn’t hands in the org at all. It’s someone senior to read the SOW before it’s signed, sit in on the architecture review, or tell you honestly whether the platform your vendor is proposing will do what they’re claiming.
We also do enablement. If you have a capable ops person who’s been handed Salesforce and is learning by trial and error in production, a structured mentoring engagement is cheaper than the mistakes and leaves you with someone who can own it.
Three ways to work together
Start wherever it fits. Most clients move between these over time.
Fixed-scope project
A defined outcome, a written scope, a price agreed before work starts. Assessments, integrations and builds usually run this way. You know the number going in.
Ongoing admin support
A monthly block of hours covering the day-to-day queue plus small builds. No long-term lock-in — thirty days’ notice either direction.
Advisory retainer
A standing arrangement for teams with their own admin who want senior review on design decisions, vendor proposals and architecture.
Before you reach out
How small is too small?
We work with orgs from around ten users up. Below that, honestly, you usually need a few hours of setup and some training rather than a consultant — and we’ll tell you so on the call rather than sell you an engagement.
Do you need access to our production org?
For an assessment, read-only access is enough and that’s what we ask for. Build work happens in a sandbox and moves to production through whatever deployment process you already use. If you don’t have one, setting that up is usually an early recommendation.
What if we already have a Salesforce admin?
That’s common and it works well. We take the projects your admin doesn’t have bandwidth or specialist depth for, and leave the day-to-day with them. Some clients use us purely as a second opinion on design decisions.
How quickly can you start?
Discovery calls usually happen within a few days of reaching out. Assessments typically start within two weeks. Ongoing support depends on current capacity — because we’re deliberately small, there’s sometimes a wait, and we’ll say so honestly rather than overcommit.
Are you available in our time zone?
We work with clients from the East Coast to the Pacific and keep overlapping hours across all four continental U.S. time zones. Meetings get scheduled in your zone, not ours.
What happens to documentation when an engagement ends?
You keep all of it. Every assessment document, field map, flow description and runbook is yours, written to be readable by whoever comes next — including a different consultancy.
Not sure which of these you need?
That’s what the discovery call is for. Describe the symptom and we’ll tell you where it usually comes from.