Pamacore Labs

Engagements

The work, and how it actually goes

Sixteen engagements I take on regularly — what the situation usually looks like, how I'd approach it, and the part that tends to cause trouble. A few include the case for not doing the project at all, because that's sometimes the right answer.

These describe project types rather than specific clients. The patterns, constraints and failure modes come from a decade of enterprise architecture work; client engagements themselves stay confidential. On a call I can go considerably deeper on anything relevant to your situation.

AI & Automation
Professional services, IT, engineering teams· 5–7 weeks

Making the document estate answer questions, so new hires stop asking people

The situation

A new engineer's first fortnight is mostly reading. Runbooks, architecture notes, SOPs, a SharePoint site with a decade of sediment in it, and a lot of context that exists only in the heads of three senior people who get interrupted constantly. Nobody can point to where the current version of anything lives.

How I'd approach it

Retrieval over the existing corpus rather than a fine-tune — AI Search for the index, Azure OpenAI for generation. Chunking that respects document structure instead of cutting every N characters, because a policy split mid-clause retrieves badly. Two non-negotiables: every answer cites its source document so people can verify it, and retrieval honours the existing permission model so it cannot surface something a new joiner shouldn't see.

What usually bites

The corpus is always worse than anyone admits at kickoff. Three versions of the same policy, no owner on half the documents, PDFs that are scans of printouts. Retrieval quality turns out to be a content-hygiene problem wearing an AI costume, and that lands around week two.

What I'd cut first

A bespoke chat interface. Put it in Teams where people already are and spend the saved time on retrieval quality, which is what decides whether anyone uses it twice.

Azure OpenAIAzure AI SearchPythonFastAPIMicrosoft TeamsAzure Functions
AI & Automation
E-commerce, SaaS, B2B services· 4–6 weeks

Ticket triage that suggests rather than decides

The situation

Tickets land in a shared mailbox and a helpdesk queue. Someone experienced spends the first hour of every day reading and routing them, and a misroute quietly costs a day of response time. Volume has grown past the point where this is a reasonable use of a senior person's morning.

How I'd approach it

Classify against the categories that actually exist in ticket history, not the ones on the org chart — those two lists are rarely the same. The model proposes a queue and a priority; the agent accepts or overrides in one click, and every override is logged as training signal. Confidence thresholds matter more than headline accuracy: routing a clear majority of tickets well and leaving the ambiguous remainder to a human beats routing everything adequately.

What usually bites

Label quality in historical data. Tickets get reassigned, closed under the wrong category, or merged, and the export reflects that mess. Part of this project is deciding what ground truth even is. It is also worth being blunt with whoever sponsors it: deflection reduces routine load, and the tickets left for humans get harder on average, so per-agent throughput does not rise the way a headline number implies.

What I'd cut first

Automated reply drafting. Triage has clear value and a small blast radius when wrong. Drafting follows once there is trust in the classifier.

Azure AI LanguageAzure OpenAIPythonFastAPIAzure FunctionsService Bus
AI & Automation
Distribution, logistics, manufacturing· 5–8 weeks

Invoice processing that hands off the hard cases instead of guessing

The situation

Accounts payable keys invoices by hand. Supplier formats vary — some PDFs, some scans, a few arriving as photographs taken on a phone. Month-end is a crunch, and the error rate climbs exactly when volume does.

How I'd approach it

Azure Document Intelligence, with a custom model trained on the handful of supplier layouts covering most of the volume and the prebuilt invoice model as fallback for the long tail. Vendor, amount, GST and PO number get extracted and validated; anything under the confidence threshold goes to an exceptions queue rather than into the accounting system. Writes happen through the ERP or Tally API — never by driving the UI, which breaks silently at the next vendor update.

What usually bites

Extraction is largely solved. The project actually lives in purchase order matching — tolerances, partial deliveries, line items that don't correspond one to one. That's where the weeks go, and it belongs in the scope conversation rather than in week four. Worth noting too that throughput gains are bounded by invoice volume, not by system capacity; the honest measure is hours returned to the finance team, not theoretical documents per day.

What I'd cut first

Handwritten annotations and non-standard attachments. Get the clean majority flowing and let the exceptions queue absorb the rest.

Azure Document Intelligence.NET CoreEF CoreTally / ERP APIAzure Blob StorageAzure SQL
AI & Automation
Multi-system operations, services firms· 4–6 weeks

Killing the monthly pack that takes two days to assemble

The situation

A management pack built by hand from five or six systems, consuming most of two days of an analyst's time. Occasionally two slides in the same deck disagree about the same number, which nobody catches until someone senior does.

How I'd approach it

Define each metric once, in one place, and compute it there. Scheduled overnight refresh into a warehouse, a semantic layer that owns the definitions, and generated commentary written over the computed figures. The language model writes narrative; it never calculates. That boundary is the whole design and it should be enforced in code rather than by convention. Alerting on threshold breaches goes to the channel people already watch.

What usually bites

Nobody agrees what an active customer is. Or a qualified lead, or the cutoff for a closed month. Reconciling those definitions is the actual project, and it is a governance exercise needing a decision-maker in the room — not just a data owner. Expect the reporting build to wait on it.

What I'd cut first

Real-time refresh. A nightly pipeline serves a monthly decision perfectly well, and building for real-time costs far more than the freshness is worth. Anyone promising both a nightly pipeline and real-time data is describing two different systems.

Azure Data FactoryAzure SynapsePower BIAzure OpenAIPython
AI & Automation
B2B SaaS, services, agencies· 3–5 weeks

Qualifying inbound leads before a human reads them

The situation

Inbound enquiries arrive from web forms, a shared inbox and social channels. Someone reads each one, decides whether it's worth pursuing, and books the good ones. Response time stretches across evenings and weekends, and the enquiries that arrive on a Friday night are the ones most likely to go cold.

How I'd approach it

Enrich the submission, score it against criteria the sales side actually uses rather than a generic framework, and route accordingly — straight to a booking link for the strong ones, a nurture sequence for the rest, and a human for anything the model is unsure about. Acknowledgement goes out immediately regardless of score, because speed of first response is the part with the clearest effect. Everything writes back to the CRM so scoring can be reviewed against what actually closed.

What usually bites

Scoring criteria are usually undocumented and partly instinct. Getting them written down means sitting with whoever currently does the qualifying and working through recent examples, including the ones they rejected. That conversation is most of the build.

What I'd cut first

Fully automated outbound sequences. Qualify and route first; automated multi-step outreach on top of an unproven score compounds any error in it.

When I'd tell you not to

Under roughly twenty enquiries a month, this doesn't pay for itself. A shared inbox rule and a booking link will do, and I'll say so.

Azure OpenAI.NET CoreCRM APIAzure FunctionsAzure SQL
AI & Automation
Agencies, professional services· 3–4 weeks

Onboarding that starts the moment a deal closes

The situation

A signed client waits several days for a welcome pack, workspace setup and a kickoff booking, because each step needs a person to remember it. The gap between signing and first contact is where early doubt sets in, and it's entirely self-inflicted.

How I'd approach it

Trigger on the CRM stage change. Provision the workspace from a template, send the welcome sequence, and offer kickoff slots immediately. Scheduled check-ins at set intervals with a short feedback prompt. The valuable part isn't the automation itself — it's that every client now gets the version of onboarding your best account manager would have delivered on a good week.

What usually bites

Templates go stale and nobody owns them. Six months on, new clients receive a welcome pack describing a service tier that no longer exists. Whoever owns the content needs to be named at handover, or this quietly degrades.

What I'd cut first

Personalised video and heavy branded assets in version one. Get the sequence reliable, then make it pretty.

.NET CoreCRM APIMicrosoft GraphAzure FunctionsAzure Logic Apps

What drives the number

Why two similar projects quote differently

Four variables account for most of the difference. Understanding them is also how you reduce the number — several are things you control.

How many systems have to talk

One system in, one system out is straightforward. Each additional integration adds its own auth, its own failure modes, and its own vendor documentation of variable quality. This is the single biggest driver on most projects.

The state of the data

Clean, consistently structured source data makes a build predictable. Twelve years of inconsistent records, duplicate masters and undocumented columns turns a five-week project into an eight-week one — and that work happens whether or not it was scoped.

Which decisions are already made

If your team already agrees what an active customer is, or how a sync conflict resolves, the build starts immediately. If not, that agreement has to be reached first, and it needs a decision-maker rather than an engineer.

Who takes it over

Handing to an internal team who will maintain it is cheaper than building something that has to run untouched for two years. The latter needs more documentation, more defensive handling, and more thought about the failure modes nobody will be watching for.

I quote a fixed price after the mapping session, not before. An estimate given without seeing your systems is a guess with a margin baked in for being wrong, and you end up paying for that margin whether or not it was needed. Indicative starting points for each type of engagement are on the pricing page.

The engagement model

Four phases, no surprises

Same shape whether it's a three-week automation or a fourteen-week application build. Each phase has a defined output you can hold me to.

01

Map the actual problem

A working session on your process — where time goes, where errors creep in, what a fix is worth. You leave with a written opportunity map whether or not we go further.

→Opportunity map + rough effort estimate
02

Scope one narrow thing

One workflow, one measurable outcome, fixed price. Deliberately small — a scope you can judge in weeks beats a roadmap you have to take on faith.

→Fixed-price proposal + success metric agreed upfront
03

Build in the open

Weekly working software, not status decks. You see the real thing in your own environment and redirect while it's still cheap to redirect.

→Working system in production, deployed to your infra
04

Hand over properly

Documentation, a walkthrough with your team, and source in your repository. You are never locked into me — that constraint keeps the work honest.

→Docs, handover session, full source ownership

What you own at the end

Full source code in your own repository. Infrastructure in your own cloud account, under your billing. Documentation written for the next engineer, not for me. No proprietary runtime, no per-seat licence, no dependency on my continued involvement.

If you want ongoing support afterwards, that's a separate conversation — never a condition of the build.

Recognise your situation in one of these?

The mapping session is free and yields something useful even if we never work together.

Book a Free Consultation