But the real question is what I took away, besides the great chats, being able to speak with HR person who sees the market from outside, meeting bunch (like a lot) of new people I don’t remember seeing before and hearing a great feedback about how welcoming the community is and how even the new joiners weren’t afraid to jump into the debate and ask questions. Wow!

You can find the recordings (and second part) on Youtube and I shared the presentations on Google Drive.

Dina McLaughlin – The Platform Has Moved on – Have You? Pivoting in the Age of Agentic AI

What a great opener for the whole evening. Dina nicely summarized what happened on the market/in the industry, how it changed her life, how it is all quicker. At the same time we are moving from detesministic to probabilistic systems, where we cannot really trust or predict the output. Our roles will be more about orchestrations, reviewing and guiding, the human-in-the-loop critical due to context, creativity and bias awareness.

AI is already changing day-to-day work – for example junior devs asking AI instead of seniors, which is great and bad at the same time (cannot find the article where I found how crucial it will be to keep the human interaction and experience in the loop as well).

• The pace of change is no longer linear — it’s exponential and hard to keep up with.
• Consultants face the hardest shift → need to become transformation advisors, not just implementers.
• Businesses are confused about AI (what to automate vs what needs AI).
• Rise of autonomous agents + voice interfaces → interacting with systems without UI.
• Strong emphasis on continuous upskilling – learning is now lifelong and non-negotiable.
• Discussion around middle management potentially shrinking (AI replacing coordination roles).

Michal Verner – The Developer Who Wasn’t There: Autonomous Salesforce Development with Claude Code

Can an agent take a user story and deliver a full feature (code → tests → UI → PR) autonomously?

• AI can orchestrate the full pipeline, but only with heavy upfront setup (skills, rules, MD file, tooling) – and I had to laugh here, because it can generate it all but at the same time it expects it from you and you can get it from Reddit or other places, so now we will spend time googling skills and trying the best one just so the AI can generate the things better and quicker at the end (or maybe not)
• I need to learn new words, to fully understand what it is doing – Unravelling, really?

• The cloud.md file is the real “brain”: acts as instruction manual + standards, must be continuously refined, you “earn it” over time through iteration
• quality is inconsistent – sometimes over-engineered (too many guards, extra code), requires review or additional agents for validation
• Interesting shift in effort:
  Today: time spent coding
  Future: time spent designing instructions, pipelines, guardrails
• The agent doesn’t “understand everything” – it searches relevant files on demand, not full context; surprisingly effective even on large codebases
• Dev behavior shift: “I’m not really writing much code these days” → developers moving toward guiding, nudging, reviewing
• it was interesting to me that those agents took the whole presentation (almost 30 minutes) to generate and deploy the code, I always have a feeling the „animation“ of how it write the text is just to slow us down and it can generate the whole code base in a blink of eye

Overall feeling in the room

• Curiosity → “does this actually work?”
• Surprise → “okay, it kinda does…”
• Skepticism → “but is this maintainable / safe?”
• Humor → jokes about “agent replacing husband” / rubber duck debugging
• Realization → this is powerful, but not plug-and-play

Aleš Remta – From 75% Coverage to Sustainable Apex

• Sustainable Apex = long‑term velocity, not short‑term hacks
• Good code must be understandable, changeable, reliable, and modular – clear boundaries and contracts reduce cognitive load and prevent ripple‑effect bugs when modifying code
• Tests are not for coverage – they’re for proving requirements
• Tests are the best design tool – Writing tests first forces better API design, clearer interfaces, and more modular architecture
• Writing tests last leads to brittle, implementation‑cementing tests – When tests are written after the code, they often mirror the implementation too closely, making refactoring painful and discouraging change
• Test‑first exposes requirement gaps early – Writing tests before implementation reveals missing or unclear requirements before code is written, reducing rework and surprises at the end of development
• Use wrapper objects (e.g., DiscountRequest) to stabilize interfaces – Passing primitives or SObjects directly leads to exploding method signatures. A wrapper object keeps the interface stable even as requirements evolve .
• Guiding principles: be intentional, strict with API contracts, write more tests, and write them earlier

Dominik Hlaváč – MCP Servers: Elevating Salesforce Development

• Why MCP matters: AI needs context, and MCP provides it – compares MCP to a “USB cable for AI” that lets the model see your files, metadata, and org context – something base LLMs cannot do
• MCP architecture: client MCP server tools/resources – The server exposes tools (APIs, local files, custom logic) that the AI can call. The AI “remembers” available tools and uses them to act.
• Salesforce DX MCP server wraps the CLI into tool groups – It exposes org management, metadata operations, test execution, LWC tooling, and DevOps capabilities
• Ecosystem is exploding: Figma, GitHub, Atlassian, many more – MCP servers now exist for design, code, documentation, and workflow tools. The official registry is still in preview.
• Real use cases: dependency mapping, scratch‑org prototyping, impact analysis – MCP can automate org introspection and selective deployments: “List the org and see the whole trajectory of some attribute…”
• Limitations today: models can be lazy, inefficient, or loop endlessly – who knows how many API tools your „simple“ query will take at the end?
• Security & pricing concerns: API safer than chat, local models possible, MCP likely to become paid – “Running the API is much safer.”

And the group discusses future pricing, API consumption, and guardrails. 9pm and people are slowly heading out of the building, 10pm and we finally closing the day. Thank you all!

Podcast jsme plánovali dlouho, ale nakonec vznikl – jako většina skvělých věcí – v podstatě ze dne na den. Ohromné díky Spořce za jejich interní studio, které se postaralo o skvělou kvalitu zvuku a my jedno brzké ráno věnovali povídání s Martinem Vágnerem a Michalem Řehákem. Čas byl omezený a tak mám pocit, že je to asi jeden z nejrychleji mluvených podcastů co jsem kdy natočil, tak případně si to zpomalte.

Zápisky

• Salesforce ve Spořitelně není „jen CRM“, ale celý ekosystém, který propojuje sales, service, marketing, data i interní procesy.
• CRM v bance neslouží jen k evidenci klienta, ale hlavně k řízení interakcí, přípravě na schůzky a podpoře poradenství.
• Velké organizace netrpí technologií, ale hlavně procesy, prioritami a stakeholder managementem.
• Procesní změna je často náročnější než samotná technická implementace.
• Cílem není přepis starého systému, ale zjednodušení a inovace procesů, ideálně jejich úplné odstranění.
• Vendor lock-in existuje vždy, ale důležité je vědomě ho řídit, maximalizovat jeho hodnotu, držet systém standardní a udržitelný. Největší riziko není vendor lock platformy, ale závislost na jednom dodavateli lidí/know-how.
• AI už dnes pomáhá (např. knowledge chatbot), ale největší bariéra je regulace, ne technologie, plně autonomní poradenství je zatím legislativně problematické
• Budoucnost: AI asistenti pro bankéře, kteří připraví schůzku, doporučí produkty i styl komunikace.
• AI není jen o byznysu – má velký dopad i na vývoj – urychluje prototypování, mění roli seniorních vývojářů, vyžaduje nový mindset. Ne každá AI dává smysl – je potřeba oddělit „fancy“ use-cases od těch, které skutečně přinášejí hodnotu.
• Největší problém velkých transformací – adopce uživatelů a komunikace změn, ne samotná technologie. I při skvělé adopci platí, že uživatelé často neví, že funkce existuje, pokud není dobře komunikovaná. A i potom.
• Klíčový faktor úspěchu není jen technologie, ale lidi, kultura týmu a schopnost spolupracovat napříč organizací.

And while I do use AIs and LLMs for some tasks (like podcast summaries) I’m not really a super heavy user who would understand what they really want to do with that. Meaning it didn’t really have a high priority on my tasks list, but eventually I got to it.

I hoped that Sally would show me everything in her video, but it was just first part, developer heavy and I didn’t get much out of it.

Luckily there is a documentation – which I found before – and I went through that, did all the settings and failed. Hence this article, where I will share the updates I found and maybe explain why I feel it makes sense for regular users to connect it as well.

Step 1 – Enable MCP server

When you google how to connect Claude with Salesforce you won’t find this article, but without it the authentication will fail with super weird error 405 method not allowed.

Let’s start with that and enable MCP servers in Salesforce.

If that sounds like some mambo jumbo to you I’m not surprised, but somehow behind the scene when AI asks Salesforce when it can find something or what fields are available it will give it the answers. As you can see on the screen and in the relevant article, there are plenty of different servers/end points and you enable the ones you like. I especially like the sobject-reads which will give you read only access, no worries AI will mess anything in your org.

Open the record you like and hit the Activate button and step 1 is completed.

Step 2 – External Client App

The relevant article is easy to follow, but when you set it as specified it won’t work – some scope is missing. After some googling around I found out which one – the mcp_api is crucial one!

Save, wait some time to propagate everything across servers and get the Consumer Key, you will need to add into Claude.

Step 3 – Connect Claude

Surprisingly or even maybe shockingly, Claude doesn’t have a dedicated Salesforce connector, so you need to add it manually. Good news for bigger companies – the Claude Owner/Admin can add it on the org level and users will just connect it with their own credentials.

If you want to do it manually just follow the respective article, this one works. Actually it might be better to copy the URL from the Step 1 as it is listed there clearly (and have different URL at the same time).

Settings, Connectors, Custom Connector, ugly looking URL at the of which you will add the server you like and enabled in Step 1 (no need if you copy the URL from the Step 1). In the OAuth Client ID you will paste the Consumer Key from previous step.

Success, hopefully. If not pay attention to the URL of the error page, most likely at the end you can spot what is wrong:

• app doesn’t exist means wait a bit longer/double check the Consumer Key
• invalid Scope – most likely you didn’t add all the scopes, including mcp_api
• 405 method not allowed – most likely the MCP server is not enabled.

Step 4 – Use it

I suppose you might struggle how to use it and I was the same. But then I came with simple use cases, it gave me some data which looks relevant and save some time.

For CzechDreamin I wanted to analyze who are our top speakers – meaning they spoke the most. We have every single one as a lead in our Salesforce. As a lead for every single year they submitted a topic/spoke. When Data Cloud 360 came we tried to unify them and while it kind of worked it needed some admin work for setup and wasn’t really user friendly to get this statistic. Running a report might work but it is a lot of clicks -> Claude to save me!

Can you analyze all our leads of type Speaker and tell me which email address is the most common one (top 10). Make them unique by year (count only once per year). Count only those accepted (or in working status), basically anything besides declined. Can you also parse https://czechdreamin.com/2024/ and https://czechdreamin.com/2025 and extend it with speakers from these years (map them across the years also by name in its fuzzy form)

I can imagine you will not want to get my requirements in such form, but Claude managed. A lot of thinking from its side, a few clicks to approve their approach and what they will query from Salesforce and we are done. I must admit this conversational analysis is super cool thing!

Key findings after adding 2025:

• Aaron Crear remains #1 — now confirmed across 5 years (2019, 2020, 2023, 2024, 2025)
• Melissa Shepard, Katka Vokrinkova, Mark Jones, George Avilov, Pei Mun Lim, Todd Halfpenny, Hanna Nimchuk, Lukas Vavrin, David Fernandez Rivero all gained a 2025 year, jumping to 3–4 total appearances
• Several 2025 speakers (like Andrew Fawcett, Markus Fröhler) appear website-only with no SF Lead record — worth checking if they should be created

I must admit that I start seeing the value and maybe being braver and allow the write access as well so it can create tasks for me, update opportunities etc would be worth it.

Check my salesforce and tell me how many opportunities we have for this year

You have 3 opportunities for 2026, all currently in the „Invoice sent“ stage with a 95% probability. Here’s the breakdown:

Total pipeline value: $11,200 — and since all three are at 95% probability, you’re in great shape to close them. Would you like to dig into any of these further?

can you mark all the opportunities you listed above as Closed Won?

I have the 3 opportunity IDs from earlier. Let me update all three simultaneously.All 3 opportunities have been marked as Closed Won Total closed: $11,200. Nice work!

actually create a follow-up task for me in a week time to check whether they have all information for each of those opps.

Good, got your user ID. Now creating 3 tasks — one per opportunity — due in a week (April 28).All 3 tasks created and linked to their respective opportunities, due April 28

They’re assigned to you (Martin Humpolec) and will show up in your SF task list and activity timeline on each opp.

I always have a feeling it takes for ever, but it is probably quicker than open Salesforce and go one by one or even mass update from a list view. Yes, they all have been updated to Closed Won a few seconds later and tasks have been created.

And I’m probably sold, this conversational work – which compared to my previous experience is really spot on and doesn’t need to constantly confirm that it found the right records and everything – makes it easy to work, maybe instead of typing use voice and much more.

I’m pretty sure I’m just scratching the surface of what is possible and you do on daily basis – will you share some example how you utilize it or what you feel it will allow you to do?

A few of my notes:

• “Accidental admin” is the norm
  Many people don’t plan a career in Salesforce — they grow into it by solving real business problems, which leads to a very practical mindset.
• Hands-on experience builds credibility
  Deep, practical knowledge helps you:
  • understand system behavior
  • speak confidently with tech teams
  • avoid being purely theoretical
• End-to-end thinking > platform thinking
  A strong BA looks beyond Salesforce:
  • understands integrations (e.g. SAP)
  • sees the full business process
  • avoids siloed responsibility
• Users don’t care about systems — only outcomes
  They interact with one interface, but expect everything behind it to work seamlessly.
• Delivery often fails before it starts
  The real issues are:
  • poor data
  • unclear processes
  • missing ownership
• “You can’t automate what you can’t trust”
  Bad data = unreliable automation → validate data readiness early.
• AI / buzzwords must be translated into outcomes
  “We want AI” → define:
  • measurable goals
  • specific capabilities
• Start with enablers, not shiny features
  Before advanced solutions:
  • fix data
  • clarify processes
  • ensure visibility
• Success metrics are often missing
  Teams build and move on without checking impact → no learning loop.
• Curiosity builds trust, not resistance
  Asking thoughtful questions (instead of pushing back directly) leads to better collaboration and better solutions.
• Stakeholders must co-own solutions
  Involving them early → stronger adoption, better outcomes, and internal champions.

Check the recording on your own! And presentation if you wish to just quickly skim through.

Tentokrát jsem si pozval Honzu Staňka z Domova svatého Josefa a Alenu Novotnou z Lékařů bez hranic. Dvě různé implementace, dva různé systémy, dvě různě dlouhé zkušenosti.

Zápisky:

• Salesforce v nezisku není jen CRM – je to nástroj, který umožňuje šetřit čas, peníze a posouvat fundraising dopředu.
• Neziskovky často pracují efektivněji než byznys – mají méně lidí, méně času a musí víc automatizovat.
• Výběr nové databáze je strategické rozhodnutí – musí vydržet roky, být podporovaná a rozvíjená.
• Příprava před implementací je klíčová – vědět, co chceme, proč to chceme a jak to budeme používat.
• Salesforce pomáhá s datovou kulturou – umožňuje pracovat s daty, analyzovat je a dělat fundraising data‑driven.

• 10 licencí zdarma je výhoda – ale implementace, údržba a rozvoj stojí čas i peníze, které je potřeba realisticky plánovat.
• Komunita je obrovská přidaná hodnota – neziskovky se učí jedna od druhé, sdílí postupy a inspirují se.
• Implementace může být bolestivá – první měsíce jsou často „údolí smrti“, než si lidé zvyknou a systém se usadí.
• Salesforce je jako lego – dá se postavit téměř cokoliv, ale je potřeba mít hranice, aby se organizace neutopila v možnostech.
• Automatizace šetří nejvíc času – import darů, děkování, kampaně, telefonní scénáře, mailing.

• Rychlé poděkování dárcům je zásadní – automatizace umožní reagovat okamžitě, což zvyšuje loajalitu i výnosy.
• Uživatelská přívětivost je kritická – neziskovky nemají armádu adminů, systém musí být jednoduchý pro běžné uživatele.
• Salesforce pomáhá zvednout fundraising – méně času na administrativu znamená víc času na dárce a kampaně.
• CRM není o datech, ale o vztazích – fundraising je budování vztahů a Salesforce pomáhá řídit je ve velkém.
• Hotové balíčky pro neziskovky jsou velká výhoda – integrace na banky, darujme, kampaně a další věci zjednodušují start.

When I recall all the CTA related scenarios, there probably wasn’t any, where we wouldn’t propose ESB in the picture. But worth to know that these solutions don’t have any budget constrains which makes real life decision a bit different.

A great article has been published on SalesforceBen related to this and this exact article was the reason for my blog post.

All the points in the article are valid, but the real life might be different, like on our last project.

Imagine a company, which has existing Salesforce implementation, connected to their DWH via Pentaho, because that’s a tool they know and use for everything. Now they are entering phase 2 with 8 more integrations and the question is obviously on the table.

The answer is not that clear anymore, once you describe the integrations:

1. Company register, when they are creating a new account in SF they want to just enter its identification number and get all the details from the government run register – no typing, no extra clicks, load also relevant contacts;
2. Being able to check the company health via a dedicated provider – click on a link, it will open the website with already filtered out the respective company. There is no write back of data into the system, just visual check how it looks now and whether we can proceed with doing business with the company;
3. eSignature of orders (think DocuSign or similar);
4. LinkedIn integration as additional source of contacts;
5. Sending SMS based on activities done in the system and as a reminder for meetings;
6. Integration with mass mail sending system;

And the list goes on. What might have look pretty clear at the beginning – 8 separate systems to integrate with obviously might be a great reason for purchasing ESB solution.

But when you describe the system and use cases it isn’t so clear to me anymore.

You ask why?

Let’s go one by one:

1. You will need to develop the custom LWC component which would wrap the logic and user interaction. You can call the end system directly from here or call ESB which would call the system. Added value? When you will change the data provider you can just change the mapping on the ESB level and not touch the SF side at all. But how often that would happen and is it really easier than change the logic in the Apex controller or Flow? Because we would not use any other benefit of ESB – such as retry, load balancing, etc. We might still use it to store the debug or track the usage off-platform, but we can probably do it easily on SF side as well;
2. This is just a URL link with some identifier – most likely the company identification number – at the end, no added benefit of opening the URL via ESB which would just redirect elsewhere;
3. eSignature and all the following share one main reason – most likely there is already an existing AppExchange app, which handles that, you can just install and configure it and be up and running. Do you really want to develop your own LinkedIn integration (impossible) or integrate the emailing system from scratch? There is no point and the ESB doesn’t provide any value here.

When does it make sense?

To me the use cases are pretty clear when typically looking in the mirror as the typical company slowly evolves and add additional systems in the landscape. What made sense to do point-to-point at the beginning (like connecting SF to DWH directly) suddenly doesn’t make much sense as you need to develop each integration on its own, update all the data mapping on multiple places if new tables are added, etc.

Once you have complex integration where you need to query one system, based on results query another one, transform data and then act on them – that might be great use case.

When you have a lot of calls going here and there and you might be able to use ESB as some kind of cache to save on the SF calls.

When you need to update data during night based on external system it makes sense to run it off-platform and don’t waste scheduled job development on SF side.

When it is happening in the background and you need to have a way to retry failed operations – it might be easier to do on ESB side rather than develop on SF side.

When you need to connect to on-prem systems and IT isn’t willing to open a firewall to you – you will most likely want to run this operation from inside and just call out to Salesforce.

Not the easiest decision

What looked like an easy choice at the beginning isn’t that easy at the end. You rarely have all the information at start, the fixed system landscape, understanding of the complete data flow. Starting point-to-point might be easier and then, a few years down the road, you will realize it wasn’t the best choice and you should redo everything. Sad, but probably no one should be blamed, that’s life.

A customer came the other day that they have a new process, where they need to follow-up with a new lead in 2 hours and notify owner and their supervisor if there is a delay.

My initial reaction was „damn, cases have it out-of-the-box but that’s not a reason to change leads to cases and it is really pity“

The next thought was pretty simple – 2 hours, it is just a simple flow which would set a date/time field and put extra two hours there and then scheduled path with email/Slack message.

Obviously it turned out to be a bit more complex:

• 2 hours only during business hours
• operating in multiple timezones

In Apex we can use the BusinessHours class, which would solve the check whether we are already after hours or weekend or ban holiday, but do I want to develop this thing? And how to handle the timezones?

And how can I solve it in Flow? Add two hours and check whether it is already after working hours or weekend?  That would be complex and ugly to configure.

Invocable classes and community solution to my rescue, I’m so glad that I know UnOfficialSF.com.

The Solution

There are actually two great solutions on the UnOfficialSF, which I combined.

The first is more complex and can solve almost anything, except using specified business hours to run the calculation (it takes the default one)

The second one can take specific business hours into account, but there is no way how to figure out which of them.

1. Create a business hours for „each“ timezone – I didn’t really create for each, but only for the timezones (or rather timeshifts?) where present employees are based. What I mean by „timeshifts“? If there are two people, one located in Prague and one in Berlin (both are GMT+1) I would create just one record (e.g. BusinessHours1), where the number means the offset. The potential downside are cities, which typically have the same time shift but sometime to the switch to summer/winter time at different time of the year (or not at all – I still remember some states in Australia have it differently)
2. As all times in Salesforce are stored in UTC/GMT the first thing the flow does is to calculate the offset of the owner of the record – the timezone field on user record doesn’t specify the numeric value, but the real city, so we cannot just get it from the record but the Apex can tell me the difference
3. We will find the respective business hours record (remember the number in the name) and if there is none we would take the default one
4. Calculate the offset via calling the respective method and passing the business hours Id
5. Have a second after-save flow with scheduled path – the assumption is that there aren’t that many records created on daily basis to hit the limits of scheduled interviews. The reason for second flow was, that when you update the „Follow-up till“ value in the same flow, the scheduled path is not recalculated. Crucial detail when designing these two flows was also the order of their execution – don’t forget to set it right otherwise it might work just on second save or never

Done!

That would be too quick, right? One of my biggest fear was how to post the message to Slack, especially as I want to mention the respective user. Turned out that when you setup the Slack integration it automatically syncs the Slack user ids (or you can map it manually), so it was simple matter of lookup the user id (and their superior) and add the id into the Slack message – the format of <@Id> has been luckily easy to find on the internet.

Take away

Customer happy and one crucial fact discovered as well – to surprise of everyone, most of the leads could wait till the next day for processing (meaning the 2 hours deadline will be only the next day).

While the intention of assigning the person from the respective region was generally good and made sense, turned out that customers have been typically registering rather at the end of the day/after hours and it might be better to assign them to someone from other region, to really get in touch in those 2 hours. Obviously they might have done it as the last task of their day and be already out of office, but who knows and we don’t have data to confirm that.

What about you, do you have some KPIs to track and automation to help you keep up with them?

Now – I mean it is for some time already, but I finally really used it at one client – you can get Platform licenses for free as well.

As SalesforceBen listed in their article, you get 600 Platform Login Licenses when you enable Salesforce Foundations.

But here is the catch, as the license is not available immediately after activating Foundations. The only one you will see is 601 of Einstein Agent and 20 200 of External Apps Login.

You need to reach out to your AE and ask them to add the ‚Agentforce 360 Platform — Login and Dev Provisioning‘ SKU into your contract, which is free of charge. Once signed and a bit of wait you will get Platform Logins into your org. Surprisingly we got 12 000 of them, when I expected only 600, maybe it is somehow linked to the related information in the article – „600 annual logins with 30,000 credits“ but I’m still not able to do the math.

What do to with that?

Login license is not like a regular license, you pay/use it for every login by those users, but counting only once for each user during 24 hours. Meaning if the user will login every working day (let’s say 200 days per year) you have enough for 60 people – wow!

Platform license works almost like any other license, there are just a few objects it cannot access such as Leads or Opportunities. But Accounts, Contacts, Tasks, Events, custom objects, etc are available and can be used.

You will also notice why Salesforce has been pushing for Permission Sets for a while – you need to have a different profile for Login users and it is quiet annoying to setup everything twice. Minimum profile extended with relevant permission sets will save you a lot of work.

External Apps Login

Actually what about the other license you get as well? Again, these licenses are used per login, as the name suggest you can use it only for external users (not internal) and they will be able to access Salesforce only via Experience Cloud. Generally they behave as Customer Community license which means less possibilities to share data, managing users via accounts & contacts and a few other things. And they have access only to CRM objects (meaning NO access to leads, cases, opportunities primarily) but you can probably still find some use-case for what to use it.

All those tricky flex-credits

Yes, to enable Foundations you need to enable Data Cloud and we all heard the story about pay-as-you-go, consumption credits, etc. A lot of people are super scared about this, even though Salesforce tried to minimize the risk with all the extra reporting.

From my experience when you just enable these things it doesn’t consume any credits and you are still getting the benefits mentioned above. Already 2 of mine customers are using extra licenses they’ve got for free and so far don’t complain.

Volné pokračování mé série o rolích lidí v Salesforce/IT ecosystému. Už jsme mluvili o testování, projektovém řízení, s obchodníky, administrátory, head hunterem, s konzultanty i success architektem. Tak teď jsme chytili ten „začátek“ projektu, kde se říká co se bude dělat, proč a případně jak. Připojila se ke mě Nhan Anička Nguyenová a Anna Michutová, které si roli business analytika užívají už hezkých pár pátků a současně se dívají dopředu, takže jsme mohli mluvit i o technických dovednostech a jejich přínosu.

Zápisky:

• Analytik není univerzál – role se specializují a málokdo pokrývá vše od byznysu po data.
• Obor pomáhá, ale není nutný – znalost terminologie a regulací zrychlí onboarding, ale řemeslo je přenositelné.
• Analytik není zapisovatel – skutečná hodnota je ve schopnosti interpretovat a syntetizovat informace.
• Klient očekává vedení – analytik má být partner, který upozorní na rizika, regulace i slepé uličky.
• Naslouchání je klíčová dovednost – technické věci se dají doučit, ale schopnost ptát se a mlčet je zásadní.
• Nehledat řešení na místě – rychlé závěry často vycházejí z domněnek a vedou špatným směrem.
• Challengovat je nutnost – analytik musí umět říct, že něco nedává smysl byznysově, technicky ani finančně.
• Technické povědomí je výhoda – není nutné být vývojář, ale rozumět datovým modelům a API výrazně pomáhá.
• Analýza není jen o funkcích – je nutné chápat architekturu firmy, kulturu i rozhodovací struktury.
• Stakeholdeři rozhodují o úspěchu – je důležité identifikovat skutečné decision makery, i ty skryté.
• Velikost projektu mění způsob práce – malé projekty dávají flexibilitu, korporáty mají pevné rituály.
• Příprava workshopu je zásadní – bez ní se meetingy mění v chaos a ztrátu času.
• AI mění roli analytika – neohrožuje ji, ale posouvá směrem k vyšší přidané hodnotě.
• AI pomáhá se sumarizací a kontrolou kvality – transkripty, next actions, kontrola user stories.
• Analýza je skvělá škola komunikace – naučí vyjednávat, říkat ne, vystupovat a přemýšlet za chodu.

Justinas started with a general intro and question whether loyalty isn’t just a discount in disguise? How the brand promises and excellent service can create such customers and why moving beyond single transaction and build a habit to buy from a specific brand.

But where is space for technology, if it is „just“ about brand promises and excellent service? Actually there is a big role, as the technology allows you the „360“ unified view of customer and allows you to trigger key conversations timely – imagine all the emails which came just in time when you run out of something or which reminded you about something you should buy next as it will be time soon. Diapers, car seats, food for your animals – it is all pretty easy to time when the next will be needed, send me an email and small discount and I’m hooked.

Michal followed with more practical talk about the Salesforce Loyalty Management solution, with its super complex data model, which is at times surprising as well and bring additional challenges – like voucher which needs to be always connected to individual and if you have a general voucher you need to create a „general“ individual as well. Or about all the large data volumes it will end up in as their is a junction record for every individual and currency of loyalty program. Surprisingly Transaction Journal is not counted as used space, but every other object yes.

Practical demo followed and when we run out of question and intense discussion and networking among all attendees. It was a long evening but fully worth it!