The client, one of the world's leading commercial vehicle manufacturers, had relied on CAS's on-premise CPQ tool for over a decade. Growing operational demands and the limitations of on-premise infrastructure created pressure to modernize, not just technically, but architecturally. The new solution needed to be cloud-native, built on standard platforms (SmartWe CRM and CAS Merlin CPQ) to ensure maintainable update paths, integrate with several existing third party services and be deployed outside of CAS's own infrastructure for the first time. The complexity was compounded by two parallel work streams serving different business units, each with their own requirements and timelines.

I sat at the intersection of the client-facing project unit and SmartWe product management, owning the coordination across solution and standard development teams. As Product Owner for the solution team, I was responsible for prioritizing and specifying requirements that fell outside the standard platform, including integration with a centralized customer database, a third-party DMS, and a custom news feature. Beyond my own team, I aligned with at least two additional standard development teams and maintained regular touchpoints with UX, project management, and the CAS Merlin CPQ unit to ensure cross-workstream consistency.

• One key architectural decision was to isolate all custom solution logic into a dedicated micro service, deployed alongside SmartWe in Kubernetes rather than embedded into the standard platform. This allowed us to maintain a clean standard codebase with clear update paths, while still delivering the client-specific functionality required. The service communicated with SmartWe via its existing APIs and Auth Server, and acted as a middleware layer between SmartWe and external systems such as the customer database and DMS. This approach proved critical for scalability and maintainability.
• Another key decision was enabling SmartWe to support MySQL alongside MariaDB. The client's deployment ran on Microsoft Azure, which no longer supported MariaDB, creating a critical infrastructure blocker. Through analysis and hands-on testing together with my development team, we built the case for extending SmartWe's database compatibility to include MySQL. This decision was essential for the stability and long-term maintainability of the Kubernetes deployment in Azure.

While important milestones were reached before I left, there were areas that could have been handled better. The database mismatch between MariaDB and MySQL was identified early, but the initial hope was that a working alternative would emerge. This delayed the decision to adopt MySQL, consuming resources and introducing additional deployment and backup challenges. In retrospect, I would have pushed harder and earlier for a clear resolution rather than waiting for circumstances to clarify.

A second challenge arose when a parallel project with overlapping scope was introduced and elevated in priority. Several features existed in both projects but with different external requirements, and the time it took to align on a unified direction spanned months. This created overhead and pushed already finished work out of scope. A more assertive push towards early alignment on shared features would have reduced this significantly.

When I left CAS, the project had reached several significant milestones and was on track to go live for the first market in summer. Core features had been deployed to external test systems and early user feedback was being collected and incorporated into ongoing refinement. The backend infrastructure was fully deployed and being adjusted based on test results. The MySQL migration had been completed and validated both internally and externally. Due to the reprioritization of the parallel project and the resulting scope shifts, certain features such as the customer database integration were still being refined at the time of my departure.

Approaching a project of this scale again, I would prioritize early deployment testing and push for technical decisions to be resolved before they become blockers. The database migration and infrastructure setup taught me that deferring critical technical decisions in the hope of a simpler solution creates more overhead than resolving them upfront.

Beyond the technical side, this project was one of the most valuable experiences of my career in terms of stakeholder management and cross-team communication. Navigating changing scopes, technical debt, differing infrastructure requirements, and multiple organizational units simultaneously taught me how to stay focused on delivery while keeping all parties aligned.

With the European guideline 2014/55/EU and the following european norm EN 16931 invoices are required to be sent fully digitally by 2028. With the advantage of being fully compliant and digitally processable which in the end should improve transparency and reduce money laundering within the european union. For this B2B it also means improved workflows and reduced effort in writing and paying invoices. Given the advantages and legislative guidelines, CAS, as a CRM leader for mid size companies in Germany, advocated the change by implementing a solution early on to provide the customers sufficient time for adoption in their workflows.

To ensure the best compatibility within all provided CAS solutions, the decision was taken to offer a service that could be used by any platform within the company. With the given boundaries, my role was not just the ensure to be fully compliant but also building a scalable and adaptable solution that - in theory - could be used by any of CAS platform. To achieve this goal I made sure to understand the regulatory restrictions and gather input from internal stakeholders on required core aspect to focus on the most valuable MVP.

• Together with my development team we decided on a micro service architecture that would be deployed within SmartWe's Kubernetes Cluster and therefore would be accessible for additional platforms.
• Within SmartWe I designed a workflow that would complement the already existing user journey to simplify the switch from a traditional paper invoice to the digital electronic invoice. This included adjusting multiple forms and adding additional logic and fall backs to ensure that the user couldn't send faulty invoices towards the micro service.
• To satisfy user needs I decided to implement XRechnung (the German standard in pure XML) and ZUGFeRD (the German hybrid standard pdf/XML). Prior discussions already revealed that both would be required since many customers still preferred a classic pdf, but in the long run the switch to XRechnung would happen regardless.
• Beyond my own development team, I acted as the central knowledge owner for the einvoicing domain, supporting three additional product teams through their integration of the micro service.

In retrospective we found out that the chosen open source library was limiting some of our use cases and lead to custom code in our version of the library. For example the library was missing some more specialized invoicing fields or had an outdated Id required for correct identification of the invoice format. With additional in depth analysis this could have been spotted earlier.

At go-live, SmartWe was fully enabled to create XRechnung and ZUGFeRD compliant invoices. The micro service was rapidly adopted by three additional CAS platforms - CAS GenesisWorld, CAS Macenas, and internal billing - making it a shared infrastructure component across the company. Acting as central knowledge owner, I supported three product teams through integration and ensured consistent implementation across platforms.

Early and thorough evaluation of third-party libraries is critical when compliance standards are involved. A more structured assessment of the Mustang library's field coverage against XRechnung requirements would have prevented custom code overhead. Beyond the technical side, this project reinforced the value of building shared infrastructure. The effort of designing for reusability paid off quickly when additional platforms adopted the service.

Our goal is to give the users a tool that does more than the bare minimum. A tool should be smart, understand the users needs and proactively reduce workloads to best support the overall goal - enabling meaningful user connections and boost sales. From the Deal Closer who loses information between back-to-back calls, to the Small Business Owner who skips documentation entirely — Smart Notes addresses a shared pain point across our core user segments.

The tool will assist the user to create notes from emails and transcribed calls and will update a new section in the users customers profile. Smart Notes will also go a step further and automatically create tasks in the CRM — setting deadlines and priority based on all known information from the conversation. The feature will be a paid add-on based on the amount of users, with running costs covered by the additional charge.

The feature is targeted to users that have regular exchanges with their customers and own the customer communication life cycle. Three personas represent the core target group: John (Deal Closer), Laura (Relationship Builder), and Iris (Business Owner/All-Rounder).

To ensure broad adoption, it is essential that the user always feels like the last instance of decision. Instead of asking for explicit approval every time, we make clear where information came from and make it easy to rewrite, reject notes, or tasks — either through the notification menu or a conclusion overlay directly after a call.

• John, the Deal Closer — Sales Manager (B2B), multiple calls/day, loses information between calls. Driver: "Does it save me time?" Highest expected adoption rate.
• Laura, the Relationship Builder — Account Manager / CSM, structured but relies on manual processes. Driver: "Can I prepare better for meetings?"
• Iris, the All-Rounder — SMB Founder, skips documentation entirely, prefers plug-and-play. Driver: "Does it require setup?" Lowest expected adoption rate.

• Must have: Compress and write relevant information into note fields with AI label · Create tasks from transcribed calls · Notification when notes are generated · Post-call modal with summary and tasks · Option to switch off completely · MS Teams and internal calling tool integration
• Should have: Option to deactivate for certain calls · Confidential mode · User feedback mechanism
• Can have: Automatic appointment scheduling · Share tasks with other users · Email communication support
• Won't have: Integration into Skype for Business

The user starts the call from within the CRM and enables recording/transcription. The feature activates automatically after purchase and can be deactivated in settings.

Once the call ends, a modal opens showing: (1) current processing step in the header (summarizing → analyzing → creating tasks), (2) a text box displaying the summary once complete, (3) a section showing created tasks linked to the summary. The user can edit the summary, re-trigger task creation, close with "Close and inform me later", or save once satisfied. All outputs are linked to the call record.

Error handling differentiates between background failures (user closed modal — notification sent, retry available in data record) and active failures (open modal — user advised to update manually). All errors are logged automatically.

Three-step process: (1) Summarize the information, (2) Extract relevant task aspects, (3) Create one or multiple tasks.

• A small local model (Llama 3 8B) summarizes the transcript quickly — output is displayed to the user while the larger model works in the background.
• Claude handles task extraction natively in JSON, reducing a critical failure point. The system prompt includes all relevant CRM fields and writing style instructions.
• This two-model architecture accelerates the perceived response time: the user reads the summary while task creation runs in parallel.
• GDPR documentation to be updated to ensure customers agree to AI usage when purchasing the add-on.

• Hallucination Handling: Low temperature to stay close to input; user feedback incorporated to identify and adjust model behavior.
• Confidence Threshold: Recall-based approach — no relevant data should be lost. Users instructed to review output.
• Feedback Loop: Like/dislike button with optional written feedback per generated output.
• Data Requirements: Access locked to information the individual user can access — no cross-user data exposure.

API calls will be limited to sensible thresholds based on persona cohort behavior analysis. Pricing will be adjusted based on real-world usage once the feature is in testing. The model is expected to perform well for most tasks but may fall short when tasks require additional context knowledge — a RAG system using previous summaries is planned as a follow-up step.

• External: LLM provider pricing changes · Changes in EU and global legislation (per-country compliance check required before release)
• Internal: Two-model chain risk — relevant information may be lost between summarization and task creation. Single-model alternative increases cost and context blind spots. · Limited resources for parallel development.

All metrics tracked per persona cohort — highest adoption expected with John, lowest with Iris.

• NSM: Number of active users in the last month (active = edited a note or changed a task on a daily basis)
• Adoption Rate: Active users / qualified users. Target: 60% from an estimated 1,000 qualified users.
• Feature activation over tenants — opt-out process, active by default after purchase
• Tasks generated by SmartNotes — quality signal vs. test data baseline
• Manual changes in AI-generated tasks and notes — quality of model output
• Model feedback ratio — thumbs up/down as leading indicator of issues
• Amount of feature purchases — lagging commercial indicator

• Product Concept Phase (Stakeholder, Product, UX)
• Technical Analysis (Product, Dev, UX)
• Feature Refinement (Product, Dev)
• Phase 1 Implementation — Core Features / Must Haves (Dev, Product, QA)
• Phase 1 Rollout → User Feedback → Next steps based on predefined features and feedback

• Product Lead — Content Approval
• Engineering Lead — Technical Feasibility
• Legal/Compliance — GDPR
• Sales — Pricing and Positioning
• UX — Design Approval